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Clause  6:  Classification  Methods 


The  technology  embodied  in  this  standard  can  be  seen  from  two  distinctly  Afferent  viewpoints, 
from  that  of  a user  interested  in  a specific  applicatitm  use  and  from  an  implementer  who  is 
reducing  the  technt^ogy  to  software  code  to  d^  with  **«*«"g>  files  or  to  impiement  a 
database.  Each  viewpoint  has  its  own  dimension,  independent  of  the  other,  and  is  further 
segregated  into  finer  categories.  It  is  an  enumeration  of  these  viewpoint  dimensions  and 
categories  that  provides  a taxonomy  useful  in  understanding  the  planned  utility  of  this 
standard. 

Application  Protocols 

A basic  objective  of  this  standard  is  to  achieve  the  successful  transfer  of  the  mfOTmation 
required  for  a given  application  area.  Information,  be  it  in  the  form  of  a sentence  or  in  the 
form  of  a digital  product  model,  consists  of  syntax  and  semantics.  The  standard  alone  only 
defines  the  basic  syntax  and  core  semantics  of  the  representation  fimnaL 

In  order  to  ensure  complete  and  reliable  informatioo  the  application  specific 

semantics  and  required  functionality  must  also  be  documented  and  controlled.  Application 
protocols  are  a formalized  methodology  for  defining  and  controlling  this  semantic  content. 

The  standard  is  designed  to  support  a broad  range  of  applications  and  information,  and  it  is 
recognized  that  few  software  products  will  support  all  of  the  standard.  Application  protocols 
allow  the  definition  of  logical  subsets  of  the  standard  and  their  usage,  as  well  as  providing 
necessary  benchmarks  for  validating  implementations.  The  exchange  of  information  using  an 
application  protocol  ensures  that  participating  organizations  agree  on  the  types  of  information 
to  be  exchanged  and  employ  corresponding  informatioo  control  procedures. 

A protocol  is  a set  of  conventions  or  rules  that  govern  the  operation  of  functional  units  to 
achieve  communication.^  The  key  concept  of  application  protocols  is  to  explicitly  link  the 
application  area’s  information  content  to  the  entities  and  ^ta  structures  to  be  exchanged. 

The  procedure  for  developing  application  protocols  involves  identifying  the  information 
requirements  of  an  application  area  and  documenting  them  in  an  informatioo  model.  This 
application  informatioo  model  is  then  used  to  select  the  corresponding  subschema  of  the 
standard  for  representing  the  required  information. 

An  application  protocol  defines  the  information  content  of  a specific  implication  area,  specifies 
the  mapping  of  the  application  information  into  data  constructs,  and  desaibes  the  restrictions 
and  conventions  required  in  implementing  these  constructs.  The  key  components  of  an 
application  protocol  are: 

L An  application  reference  model 

2.  The  selected  subschema  of  the  standard 

3.  The  mappings  between  the  model  and  the  subschema 

4.  An  appUcation  protocol  format  specification  with  a protocol  usage  guide 

5.  A well  defined  testing  methodology  with  a set  of  application  protocol 
format  test  cases. 
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Implementatioii  Arehitectart  s 

la  the  earreat  world  of  product  data  @ehaage,  a variety  of  ^esis  are  able  to  eommunicate 
theff  data  ooly  through  standards  whose  unplemeatatioa  k tern  through  tome  type  of  standard 
cxdhacge  fmrmat  file.  NaturaUy,  each  ^em  k implemented  in  a &shion  that  k smtable  for 
ks  oompiuer  environment  and  akho^^  there  are  a wide  variety  of  eomputer  environments, 
^mmon  ar^itectural  com^nents  are  found.  Significant  benefits  in  the  data  mmhange  process 
can  be  realized  if  eommon  mplementadon  ^mpon^ts,  whi^  wae  developed  b^ause  of 
common  computer  environments,  m-e  re@3gmzed  md  otploked. 

Therefore,  the  pmp^e  of  distinguishing  levels  k to  improve  data  etch^ge  by  imderstanding 
various  eomputer  system  architedur^  Arehite^ures  ean  be  imderstood  by  virtue  of  being 
eompared  against  a common  architecture.  On^  k k available,  tUs  informadon  k meant  to  be 
used  by  ^em  developers  adio  are  r^f^nsible  {or  dfedgnmg  exchange/sharing 
archkedtures.  Those  system  developers  ^ use  that  mformadon  to  reojgaize  'connect  points’ 
between  different  ardutecTur^  which  ean  then  be  bridged  for  mcue  effldent  and  effective 
data  exchange.  In  order  to  bridge  those  '^nne^  points',  tfandards  must  be  ^ablished  at 
those  interfa^s. 

A fir^  assmnpdon  k that  a variety  of  snplementadons  are  derivable  from  the  same  conceptual 
schema.  In  t^  ease,  aU  knplementadons  must  be  derived  from  the  mtep^ted  product  data 
model  (IPDM)  ranceptual  schema  defined  in  Cause  4.  A ^cond  assumpdon  k that  the 
impiementadon  levels  mmt  not  be  mutually  eidusive.  Utat  k,  a l^el  1 nnplemexitadon  must 
have  a well  defined  mapping  into  a level  ^ 3,  or  4 impiementadon.  It  would  be  unacceptable 
for  a level  (i)  mplementadon  to  be  isolated  and  unable  to  ^nmuni^e  with  a level  (i-tl) 
impiementadon. 


Current  Approach 

At  this  time,  du'ee  standard  interfaces  are  being  inve^i^ted.  They  are: 

Exchange  Format  FUe  (included  in  this  document) 

Access  Software  (a  standard  softvme  bm^g) 

Query  Language  (a  standard  definidon/manipuladon  language) 


Eleven  oiteria  have  been  proposed  to  be  used  in  the  refinement  of  each  interface.  They  are 
listed  below. 

1.  Can  the  impiementadon  read  / vmte  to  the  Aand^d  exchange  format  file  ? 

2.  Can  the  system  generate  / aec^  the  standard  working  form  ? 

3.  What  is  the  granulari^  of  the  acce^ble  data  in  this  impiementadon  ? 

Can  quety  on  a single  endty  attribute 
C^  que^  on  muldple  endty  attributes 
Can  query  on  a single  entity 
Can  query  on  multiple  endues 
Can  query  on  a ringle  model 
Can  query  tm  muldple  models 


N286 


What  standard  forms  of  a data  query  are  supported  for  this  implementation  ? 

No  standard  query  form  supported 
Standard  function  calls  only 
Standard  interactive  DML  only 
Standard  batch  DML  only 
AH  standard  forms  of  query 

What  standard  forms  of  data  query  response  are  supported  for  this  application 

No  standard  fmms  of  data  query  response  are  supported 

Standard  function’s  output  parameters  only 

Standard  reply  to  a file 

Standard  reply  to  an  output  device 

All  standard  forms  of  reply 

What  physical  locations  for  the  data  can  the  implementation  support  ? 

In  local  computer  memory 

On  local  computer  disk 

On  local  and/or  remote  computers 

What  are  the  logical  navigational  capabilities  of  the  implementation  against  the 
integrated  produa  data  model  ? 

Hierarchical  queries  supported 
Network  queries  sup(>orted 
Relational  queries  supported 
Other 

What  are  the  constraint  checking  capabilities  of  the  implementation  ? 

IF  IT  IS  PERFORMED 
No  constraint  checking 
Some  constraint  checking 
All  constraint  diecking 
WHAT 

Simple  constraint  checking 
Complex  constraint  checking 
HOW 

Performed  by  hard-coded  function  calls 
Performed  by  executing  external  directives 
Performed  by  other  means 
WHEN 

Performed  once  when  data  is  loaded  into  system 
Performed  each  time  data  is  updated 
Performed  each  time  data  is  used 

What  is  the  automation  level  of  the  data  sharing  process  ? 

Not  automated  (Le.  manual  only) 

Partially  automated  (e^  automatic  notificatiotL,  some  manual  steps) 

Fully  automated  (updates  occur  automatically,  always  current  data) 
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10.  Can  the  implemeatation  accept/use  User>Defined  data  ? 

Cannot  accept  User*Defined  data 

Can  accept,  store  and  retrieve  for  downstream  processes  bat  cannot  use 
Can  accept  and  use  User«Defined  data 

IL  What  configuration  control  capabilities  are  supported  7 

No  configuration  controls  provided 

Limited  configuration  controls  available,  if  so,  miiat  kinds  ? 


The  Current  Working  Definition 

Although  not  fuDy  comprehensive,  the  fc^owing  implementation  level  definitions  are  useful  in 
classifying  implementations  of  this  standard. 

LEVEL  1 FILE  EXCHANGE 

Product  data  is  translated  into  or  out  of  the  standard  exchange  format  file  using  non-standard 
software.  The  data  in  the  exchange  file  is  derived  from  the  ffDM.  The  granularity  of  the  data 
in  the  exchange  &e  will  range  from  the  multi-model  level  to  the  entity  level.  No  standard 
forms  of  query  are  defined  for  the  product  data  when  in  this  form.  No  standard  navigational 
capabilities  are  defined  for  the  product  data  when  in  this  form.  No  standard  validity 
constraint  checks  are  defined  for  the  product  data  when  in  this  form.  The  automation  level 
of  the  data  sharing  process  is  not  defined  when  the  product  data  is  in  this  form. 


LEVEL  2 WORKING  FORM  EXCHANGE 

Product  data  is  translated  mto  or  out  of  the  standard  working  form.  The  product  data  m the 
working  form  is  derived  fiom  the  IPDM.  The  granularity  of  the  data  in  the  working  form  will 
range  from  the  model  level  to  the  entity  level  There  must  be  a standard  mapping  of  product 
data  from  the  exchange  format  file  form.  Product  data  in  the  working  form  is  accessed  via 
standard  access  software  function  ealU.  The  access  software  must  support  relational  network, 
or  hierarchical  types  of  queries  against  the  product  data.  The  access  software  has  no  database 
capabilities  beyond  data  manipulation  and  navigational  capabilities.  The  access  software  does 
not  enforce  validity  constraints.  The  automation  level  of  the  data  sharing  process  is  not 
defined  when  the  product  data  is  in  this  form. 


LEVEL  3 DATABASE  EXCHANGE 

Product  data  is  translated  into  or  out  of  a Database  Management  System  (DBMS).  The 
product  data  in  the  DBMS  is  derived  from  the  IPDM.  The  granularity  of  the  data  in  the 
DBMS  will  range  from  the  multi-model  level  to  the  entity  level  The  DBMS  must  be  accessable 
by  standard  exchange  format  files,  standard  access  software  function  calls,  or  standard  Data 
Manipulation  Language  statements.  The  DBMS  must  support  relational  network,  or  hierarchical 
types  of  queries  against  the  product  data.  The  DBMS  will  not  enforce  validity  constraints.  The 
data  sharing  process  is  fully  automated  when  the  product  data  is  in  this  form. 
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LEVEL  4 KNOWLEDGEBASE  EXCHANGE 

Product  data  is  translated  into  or  out  of  a Knowledgebase  Management  System  (KBMS).  The 
product  data  m the  KBMS  is  derived  from  the  IPDM.  The  granularity  of  the  data  in  the 
KBMS  win  range  frt>m  the  multi-model  level  to  the  entity  level  The  KBMS  must  be 
accessable  by  standard  exchange  format  files,  standard  access  software  function  or 
ttandard  Data  Manipulation  language  statements.  The  KBMS  must  support  relational,  network, 
or  hierarchical  types  of  queries  ag»tfKt  the  product  data.  The  KBMS  will  enforce  all  (tf  the 
validity  constraints  specified  in  the  standard.  The  data  sharing  process  is  fully  automated 
when  the  product  dka  is  in  this  form. 
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Annex  A The  Express  Language 

A.l  Introduction  to  Express 

This  section  introduces  the  major  concepts  on  which  the  Express  lan^age  is  based  and  explains 
the  objectives  and  requirements  established  for  an  information  modeling  language. 


A. 1.1  Purpose 

The  goal  of  an  information  modeling  endeavor  is  to  precisely  describe  some  subset  of  the  world 
we  know. 

Express  is  a language  that  allows  us  to  formulate  a precise  information  specification  in  terms 
that  people  can  understand,  and  that  computers  can  directly  employ. 


A. 1.2  Formal  Languages 

A language  such  as  English  is  a means  of  communicating  ideas.  English  can  be  written,  spo- 
ken, or  signed.  Meaning  is  largely  independent  of  the  method  of  articulation,  although  some 
communication  methods  are  more  robust  and  precise  than  others. 

Express  is  a specialued  language  used  to  communicate  about  a subset  the  knowledge  we  have 
about  the  world  around  us.  This  language  allows  us  to  say  what  we  know  about  information 
that  may  be  used  by  an  information  system. 

Express  provides  the  words,  syntax,  and  grammar  needed  to  describe  a Universe  of  Discourse  in 
a uniform,  precise,  and  compact  manner.  English  could  be  used  for  this  purpose,  but  English 
(or  any  natural  language)  is  anything  but  uniform,  precise,  or  compact.  A formal  structured 
language  is  needed  to  restrict  meanings  in  order  that  a high  degree  of  common  understanding 
can  be  achieved. 

Express  is  not  itself  a methodology.  A methodology  is  an  orderly  process  that  helps  to  accom- 
plish some  end  objective.  But  Express  is  a formal  language  that  could  be  used  as  part  of  a 
methodology  aimed  at  creating  an  information  model. 

A. 1.3  Objectives 

The  design  of  Express  was  guided  by  three  basic  objectives; 


• to  provide  a lot  of  expressive  power, 

• to  enable  the  separation  of  abstract  and  concrete  ideas,  and 

• to  treat  information  units  as  general  information  resources. 


1 


N287 


A. 1.4  Expressive  Power 

Producing  an  information  model  of  a complex  subject  area  like  Product  Data  demands  a lot  of 
expressive  power.  The  first  objective  of  Ezpreu  is  to  allow  knowledgeable  people  to  formally 
document  their  knowledge.  That  formal  expression  can  then  be  used  by  a rariety  of  people. 
The  people  that  will  read  Ezprt»$  arc  likely  to  have  varying  degrees  of  understanding  about  the 
subject. 


A.1.5  Separation  of  Abstract  and  Concrete  Ideas 

Every  user  will  not  have  the  same  need  for  detail.  Experts  in  a subject  area  will  demand  a 
greater  degree  of  detail  than  those  casually  interested  the  subject.  The  separation  of  abstract 
&om  concrete  views  helps  to  tailor  the  specification  to  the  needs  of  the  user. 

The  separation  of  abstract  and  concrete  concepts  requires  a different  vocabulary.  The  vocab- 
ulary used  to  express  abstract  ideas  is,  by  intention,  vague.  The  vocabulary  used  to  express 
concrete  ideas  is,  by  necessity,  exact.  For  example,  during  the  abstract  stage  we  might  say  that 
the  X component  of  a point  is  simply  a number.  The  concrete  view  might  be  that  X must  be  an 
integer  number  with  nine  digits  of  precision,  or  that  it  must  be  a real  (floating  point)  number 
of  some  kind. 


A. 1.6  General  Information  Resource 

An  entity  represents  some  ides  that  is  important  to  the  UoD  being  described.  The  context  in 
which  an  entity  is  used  should  not  alter  its  meaning,  nor  should  the  evolution  of  the  information 
model  over  time. 

The  idea  that  an  information  object  has  to  be  a stable  resource  is  of  paramount  importance  to 
the  orderly  growth  of  this  standard. 


A. 1.7  Requirements 

Express  is  designed  to  satisfy  the  four  basic  requirements  described  below.  Other  requirements 
such  as  ease  of  use  are  addressed  also,  but  are  not  discussed  in  detail  in  this  document. 

The  four  basic  requirements  are; 

• modeling  the  things  of  interest, 

• defining  the  constraints  that  are  to  be  imposed  upon  those  things, 

• defining  the  operations  in  which  those  things  participate,  and 

• modeling  in  a computer  sensible  manner. 
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A. 1.8  Modeling  of  Things 

An  entity  is  something  of  interest.  An  entity  represents  an  idea  and  is  defined  in  terms  of  a set 
of  attributes  by  which  the  idea  is  realized.  The  set  of  attributes  that  make  up  an  entity  often 
do  not  have  a one  to  one  cormpondence  to  the  physical  record  structures  found  in  a database. 

Abstraction  separates  the  idea  an  entity  represents  from  the  set  of  attributes  chosen  to  rep  re* 
sent  it.  For  example,  point  is  an  idea,  and  X,  Y,  Z are  the  names  of  the  attributes  commonly 
used  to  realize  that  idea.  It  is  important  to  be  able  to  deal  with  either  the  idea  or  the  details 
that  make  up  the  idea  separately  and  selectively.  The  term  abstract  is  used  for  the  idea  that 
the  entity  represents.  The  term  concrete  is  used  for  the  details  of  which  the  entity  is  composed. 

The  abstract  component  provides  a high  level  view  of  the  schema.  The  most  important  infor- 
mation is  raised  to  a level  where  it  may  be  seen  easily.  The  details  of  how  those  things  are 
defined  are  hidden.  At  the  abstract  level  the  idea  of  a geometric  line  is  important,  not  the 
particulars  of  how  the  line  is  defined.  At  the  abstract  level  it  is  not  even  important  that  the 
line  has  a concrete  definition. 

The  concrete  component  reveals  the  ingredients  that  make  up  the  definition  of  an  entity.  At  the 
concrete  stage  of  the  development  of  a schema  it  becomes  important  to  fix  on  a set  of  attributes 
that  define  an  entity. 

Each  attribute  is  made  up  of  two  components:  a type  and  a name  that  describes  the  role  that 
the  type  plays  in  the  definition  of  an  entity.  For  example,  a number  plays  the  role  of  the  X 
component  of  a Point  entity.  A type  is  a realization  of  the  role.  At  the  abstract  level  these 
types  have  little  or  no  meaning.  However,  at  the  concrete  level,  types  are  necessary  to  shape 
the  choices  made  about  how  a particular  entity  is  viewed  by  the  enterprise.  For  example,  at 
the  abstract  level,  "circle”  is  self-evident.  A circle  is  a plane  curve  everywhere  equidistant  from 
a given  fixed  point,  its  center.  However,  this  definition  is  not  very  useful  when  the  circle  is 
processed  by  a computer.  Choices  must  be  made  about  the  set  of  attributes  necessary  to  real- 
ize this  concept.  Therefore,  we  might  elect  to  use  attributes  named  Center,  Axis,  and  Radius, 
where  Center  is  a point  (type).  Axis  is  a vector,  and  Radius  is  a floating  point  number. 

A well  chosen  role  name  has  an  abstractive  quality.  The  role  name  Radius  is  abstract.  The  fact 
that  Radius  is  to  be  represented  as  a floating  point  number  is  concrete.  At  some  stage  in  the 
development  of  a schema,  a specific  type  must  be  associated  with  each  attribute. 


A. 1.9  Modeling  of  Rules 

A rule  (constraint)  stipulates  a condition  which  must  be  true  within  a UoD.  That  is,  it  estab- 
lishes a fact.  A database  is  in  a valid  state  when  every  rule  is  true. 

Rules  can  be  written  to  stipulate  a variety  of  conditions: 

• discrete  values;  e.g.,  radius  cannot  be  less  than  zero. 

• combinations  of  discrete  values;  e.g.,  June  has  no  more  than  30  days. 
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• uniqueness;  e.g.,  every  employee  identification  in  a database  must  be  different;  no  point 
can  be  the  same  as  any  other  point  in  the  definition  of  a spline. 

• cardinality;  e.g.,  for  each  spline  there  must  be  at  least  two,  but  not  more  than  30  control 
points;  no  edge  can  exist  unless  it  is  used  in  the  definition  of  exactly  two  loops. 

• a variety  of  different  global  constraints;  e.g.,  the  sum  of  the  debits  must  equal  the  sum  of 
the  credits;  there  must  be  one  registered  nurse  on  duty  for  every  eight  occupied  beds;  the 
machine  tool  spindle  direction  must  agree  with  the  handedness  of  the  cutter;  etc. 

A rule  written  as  part  of  an  entity  declaration  is  called  a local  rule.  Local  rules  apply  only  to 
the  values  of  those  attributes  that  exist  within  an  entity  instance  or  to  values  accessed  through 
a defining  relationship.  Local  rules  can  deal  with  single  attributes  or  combinations  of  attributes. 

A rule  written  as  part  of  a schema  is  called  a global  rule.  Global  rules  potentially  deal  with 
every  instance  of  every  type  of  entity  to  which  the  rule  applies.  For  example,  a global  rule 
might  say  that  at  least  one  point  must  exist  at  the  origin.  An  examination  of  the  set  of  point 
instances  might  find  an  origin  point  right  away,  but  it  could  be  that  every  point  in  the  set  has 
to  be  examined  to  determine  whether  the  rule  is  satisfied  or  not. 

The  rules  described  in  an  Exprtu  schema  define  a valid  end  state.  The  state  of  an  Information 
System  during  a transition  &om  one  state  to  another  is  not  addressed.  Furthermore,  a rule 
does  not  address  the  problem  of  recovering  from  a rule  violation. 


A. 1.10  Modeling  of  Operations 

An  operation  establishes  how  an  entity  may  be  employed  within  the  Universe  of  Discourse 
(UoD).  Operations  on  numbers  such  as  addition,  subtraction,  multiplication,  and  division  are 
universal.  The  set  of  operations  that  apply  to  numbers  provide  a framework  for  all  who  wish  to 
employ  mathematics.  The  same  reasoning  spiles  to  geometric  elements,  bills  of  material,  and 
other  product  data.  Once  a set  of  operations  is  defined  for  an  entity,  that  knowledge  becomes 
a valuable  resource  to  those  who  wish  to  deal  with  product  definition  data  in  a uniform  manner. 

An  operation  often  has  a symbolic  representation.  Addition  is  usually  written  in  infix  notation 
as  in: 


nuaber  * nunber 

The  two  numbers  are  the  operands  and  the  + symbol  is  the  operator. 

In  computer  programming  languages,  operations  not  accounted  for  symbolically  are  written  as 
functions.  For  example,  a square  root  operation  is  often  implemented  as  a function.  Functions 
are  sometimes  used  instead  of  operations  because  keyboards  do  not  have  appropriate  symbols. 

Various  programming  languages  implement  the  same  operation  in  different  ways.  Pascal  imple- 
ments the  modulo  operation  as  the  compound  symbol  MOD  (X  MOD  Y)  while  PL/I  implements 
the  same  operation  as  the  built-in  function  MOD(X,Y).  In  either  case,  the  built-in  operations 
almost  always  permit  generic  inputs,  i.e.,  either  SQRT(IO)  or  SQRT(IO.O)  or  SQRT(l.El)  is 
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permitted.  The  compiler  recognizes  the  input  type  and  invokes  the  ^propriate  algorithm. 

Express  allows  operations  to  be  written  as  functions.  Generic  types  can  be  used  to  avoid  the 
problem  of  developing  a specific  function  for  each  permissible  input  type. 


A.1.11  Computer  Processable 

The  problem  of  constructing  an  information  model  of  Product  Data  b too  large  to  manage 
without  computer  assist.  For  this  reason,  the  modeling  language  must  be  processable  by  a 
computer  while  still  being  usable  by  people.  The  effect  of  this  requirement  is  that  Express  must 
be  a structured  language;  computers  cannot  deal  effectively  with  unstructured  input  such  as 
natural  language  or  graphics.  Alternate  forms  of  Express  may  be  generated  as  a by-product 
of  computer  processing  to  aid  human  understanding.  Some  of  these  alternate  forms  of  output 
could  be  syntactic  and  semantic  analysis,  graphics,  a table  of  contents  or  index,  an  implemen- 
tation data  structure,  or  even  a form  of  natural  language. 


A. 1.12  Overview  of  the  Elements  of  Express 

The  main  descriptive  elements  of  Express  are: 


Schema 

Type 

Entity 

Algorithm 

Function 

Procedure 

Rule 


The  schema  is  a description  of  a UoD  and  is  composed  of  declarations  of  types,  entities,  func- 
tions and  the  like.  The  schema  is  roughly  similar  to  a description  of  a database. 

A type  describes  the  characteristics  of  the  data  that  is  used  to  represent  entities. 

The  entity  describes  the  things  of  interest  to  a UoD.  These  elements  are  roughly  similar  to 
records  that  occur  in  a database. 

Rules  define  the  constraints  on  entities  and  attributes  that  must  be  enforced  by  the  information 
system. 

Functions,  procedures,  and  rules  are  used  to  describe  the  behavior  of  things. 


5 


N287 


A. 1.13  The  Schema 

A Khema  is  a description  of  all  of  the  things  of  interest  to  a UoD.  The  entities  declared  in  a 
schema  will  later  appear  as  record  occurrences  in  a database  (although  not  necessarily  on  a 
one-to-one  basis).  Rules  and  operations  will  exist  as  part  of  application  programs  or  database 
management  system 


A.1.14  Types 

A type  is  a representation  of  data.  Exprt$$  provides  a number  of  built-in  types  as  well  as  a 
facility  for  defining  extensions  to  the  built-in  type  set.  These  built-in  types  are  grouped  into 
the  following  categories:  base  types,  aggregation  types,  entity  tyi>es,  function  types,  and  enu- 
meration types. 


• base  types  are  the  stuff  of  which  databases  are  built:  real  and  integer  numbers,  logical 
(truth  values),  and  (character)  strings. 

• aggregation  types  define  collections  of  like  things.  They  are  the  array  type,  list  type,  and 
set  type. 

• entity  may  be  used  as  a data  type. 

• function  may  be  used  as  a type  to  show  how  attributes  may  be  derived  from  other  at- 
tributes. 

• enumeration  typ>e  specifies,  in  order,  all  of  its  possible  values  of  something  by  name. 

A. 1.15  Entity 

An  entity  is  an  object,  concept,  or  idea  that  has  meaning  to  the  UoD.  It  represents  an  infor- 
mation unit,  which  may  be  exchanged  between  users. 

The  nzime  given  to  an  entity  should  docribe  the  role  it  plays  within  the  UoD.  An  entity  is 
defined  by  a set  of  attributes.  The  behavior  of  an  entity  is  defined  by  a set  of  rules.  Its  purpose 
is  defined  by  the  operations  performed  on  it. 

An  attribute  is  either  a fact  about  an  entity  or  the  data  from  which  facts  may  be  derived.  Each 
attributes  has  a name  that  is  unique  within  the  scope  of  an  entity.  The  name  (of  the  attribute) 
should  describe  the  role  the  it  plays  in  the  definition  of  an  entity.  An  attribute  is  defined  in 
terms  of  a type.  The  type  defines  how  the  role  is  realized.  The  behavior  of  an  attribute  is 
defined  by  the  characteristics  of  its  type  and  any  additional  rules  used  to  further  constrain  its 
behavior. 


A. 1.16  Algorithms  - Function  and  Procedure 

Algorithms  are  an  integral  part  of  a schema  and  are  used  to  define  the  constraints  that  govern 
entities  and  attributes.  The  liberal  use  of  algorithms  in  a schema  contribute  to  the  understand- 
ing of  entities  and  their  behavior. 
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Ab  Algorithm  if  a sequence  of  operAtions  on  dAtA  thAt  produces  ah  end  stAte.  The  end  stAte 
depends  on  whether  the  Algorithm  if  a function,  procedure,  or  rule. 


• the  function  yields  a type  as  a result, 

• the  procedure  mey  operAte  on  dAtA  in  a variety  of  ways. 

• the  rule  operates  on  the  model  as  a whole,  and  signals  any  global  inconsistencies  in  it. 

A. 1.17  Reference  Manual 

The  Reference  Manual  explains  how  the  elements  of  Express  are  used.  Each  element  is  presented 
in  its  own  context  with  examples.  Simple  elements  of  Express  are  introduced  first,  and  more 
complex  ideas  are  presented  in  an  incremental  manner. 

1.  Character  Set 

2.  Operators 

3.  Keywords 

4.  Identifiers 

5.  Literals 

6.  Directives 

7.  Types 

8.  Built-in  Constants 

9.  Built-in  Functions 

10.  Built-in  Procedures 

11.  Statements  and  Blocks 

12.  Expressions 

Note  - See  Part  iii  (the  Syntax  Specification)  for  a description  of  the  notation  used  for  the 
syntax  examples  in  this  section. 

A. 2 Character  Set 

The  Express  language  is  written  as  a string  of  characters  which  conform  to  certain  rules.  These 
characters,  except  for  whitespace,  are  combined  to  form  tokens.  Tokens  are  called  symbols, 
keywords,  identifiers,  or  literals.  The  base  character  set  used  to  write  Express  is: 

A. 2.1  Digits 

The  Arabic  digits: 

0123456789 
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A. 2. 2 Letters 

The  lower  &nd  upper  cam  letters  of  the  English  alphabet: 

abedelghij  kle&opqrstUTvxjz 
ABCDEFGEIJKLMNOPQESTUVWZTZ 

A. 2.3  Underscore 

The  underscore  character  can  be  used  as  a letter  when  forming  identifiers,  except  the  underscore 
cannot  be  used  as  the  first  character. 


A. 2. 4 Special  Characters 


A. 2. 5 Whitespace 

Whitespace  can  be  uMd  to  Mparate  tokens  and  is  often  used  to  improve  the  structure  and 
readability  of  the  written  language,  i.e.,  to  indent  sections  or  leave  blank  lines.  The  liberal  um 
of  whitespace  is  encouraged. 

A. 2. 5.1  Space  Character 

One  or  more  blank  spaces  can  appear  between  two  tokens. 

A. 2. 5. 2 Tab  Character 

The  tab  character  is  treated  as  a space. 

A. 2. 5. 3 Newline 

The  newline  marks  the  physical  end  of  a source  line.  If  the  record  is  variable  length,  the  newline 
is  a Mquence  of  non-printable  characters.  For  fixed  length  records  the  newline  is  the  physical 
end  of  the  record.  In  either  case,  newline  is  treated  as  a space.  Newline  is  significant  only  when 
it  terminates  a tail  remark  or  abnormally  terminates  a string  literal. 

A. 2. 5. 4 Remark 

A remark  is  treated  as  whitespace.  There  are  two  forms  of  a remark.  The  embedded  remark 
can  be  placed  between  any  two  tokens.  The  tail  remark  must  be  at  the  end  of  a line.  In  either 
case,  a remark  is  treated  as  documentation  and  is  not  processed  as  part  of  the  language. 
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A. 2. 5. 4.1  Embedded  Remark 

The  character  pair  ’(*’  denotes  the  start  of  an  embedded  remark  and  the  character  pair  ’*)’ 
denotes  its  end.  An  embedded  remark  can  appear  between  any  two  tokens. 

Any  character  can  be  written  between  the  start  and  end  of  a remark.  Embedded  remarks  can 
span  several  physical  lines. 

Embedded  remarks  can  be  nested.  For  example,  the  following  remark  would  be  handled  suc- 
cessfully. 


(*  The  (*  syabol  atarts  a reaark,  and  •)  ends  it  *) 

Example: 


(•  anything  can  go  here  •) 

A. 2. 5. 4. 2 Tail  Remark 

The  tail  remark  must  be  written  at  the  end  of  a physical  line.  The  character  pair  starts 
the  tail  remark  and  a newline  terminates  it. 

Example: 


*■*  this  is  a reaark  that  ends  with  a newline 
A. 3 Operators 

Operators  denote  some  action  that  is  performed  on  an  operand  or  a pair  of  operands. 
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* multiplication 

**  exponentiation 

* addition 

- aubtraction,  unary  negation 

/ division,  real 

< less  than 

■ equal 

> greater  than 

<■  leas  than  or  equal 

<>  not  equal 

>■  greater  than  or  equal 

: ■ assignment 

: ■ : instance  identity 

: <> : instance  not  identity 

I I string  concatenation 

and  boolean  and 

div  division,  integer 

in  membership 

like  string  wildcard 

mod  modulo  (remainder  after  integer  division) 
not  logical  negation 

or  inclusive  or 

xor  exclusive  or 

The  relationship  cardinality  operator  produces  a logical  result  given  objects  that  participate  in 
a relationship.  It  is  not  written  as  a single  token. 

Note  - Some  operators  such  as  * are  overloaded;  i.e.,  the  meaning  of  the  op>erator  depends 
on  the  operands  and  the  operator.  The  * operator  means  addition  when  used  with  number 
operands,  but  it  means  inclusion  when  used  with  sets  and  set  elements.  The  exact  usage  of 
operators  is  explained  for  each  type. 

A. 4 Reserved  Words 

The  reserved  words  of  Express  are  either  keywords  or  the  names  of  built-in  constants,  functions, 
or  procedures.  None  of  the  reserved  words  can  be  used  as  an  identifier.  The  reserved  words  of 
Express  are  shown  below.  A reserved  word  can  be  written  using  any  combination  of  upper  and 
lower  case  letters. 

Reserved  Words 


4.... ......................................4 

I AGGREGATE  I AND  I ARRAY  I AS  I 
I ASSUME  I BEGIN  I BY  I CASE  I 
I DEFINE  I DERIVE  I DIV  I DYNAMIC  I 
I ELSE  I END  I END.CASE  I END.ENTITY  I 
I END.FUNCTION  I END.IF  I END.LOCAL  I END.MAP  I 
I END.PROCEDURE  I END.REPEAT  I END.RULE  I END.SCHEMA  I 
I END.TYPE  I ENTITY  I ENUMERATION  I ESCAPE  I 
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EVERTTHING 

FOR 

IF 

INTERNAL 

LOGICAL 

HULL 

OR 

REPEAT 

SCHEMA 

STRING 

TO 

USES 

WHILE 


EXCEPT 

FROM 

IN 

LIKE 

MAP 

NUMBER 

OTHERWISE 

RETURN 

SELECT 

SUBTTPE 

TYPE 

VAR 

WITH 


EXPORT 

FUNCTION 

INCLUDE 

LIST 

MOD 

OF 

PROCEDURE 

RETYPE 

SET 

SUPERTYPE 

UNIQUE 

VARYING 

XOR 


EXTERNAL 

GENERIC 

INTEGER 

LOCAL 

NOT 

OPTIONAL 

REAL 

RULE 

SKIP 

THEN 

UNTIL 

WHERE 


Biiilt'iii  Functions 


1 ABS 

1 ACOS 

1 ASIN 

1 ATAN 

1 

1 COS 

1 EXISTS 

1 EXP 

1 HIBOUND 

1 

1 LOBOUND 

1 LOG 

1 LOGIC 

1 L0G2 

1 

1 ODD 

1 SIN 

1 SIZEOF 

1 SORT 

1 

1 TAN 

1 TYPEOF 

1 VALUE 

1 

1 

Built-in  Procedures 


4 ... 4 

I INSERT  I NULLIFY  I VIOLATION  I I 

4 4 


Built-in  Constants 


4 ............. ............... ...... 4 

I • i FALSE  I PI  I TRUE  I 

I UNKNOWN  I I I I 

4 .......... ....... ..... 4 

Note  - The  "pound  sign”  character  represents  the  notion  of  an  indeterminate  bound  in  an 
aggregate  type. 

A. 5 Identifiers 

Identifiers  are  names  given  to  the  elements  being  defined  in  a schema.  An  identifier  must  not 
be  the  same  as  an  EzpresB  reserved  word. 
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The  first  character  of  an  identifier  must  be  a letter.  The  remaining  characters,  if  any,  can  be 
any  combination  of  letters,  digits,  or  the  underscore  character.  Letters  are  not  case  sensitive  as 
upper  and  lower  case  letters  are  treated  as  equal. 

Identifiers  have  scope.  An  identifier  can  be  declared  only  once  within  the  same  scope. 

Sometimes  it  is  necessary  to  * qualify*  an  identifier.  This  occurs  when  addressing  an  attribute 
of  an  entity  or  when  specifying  a particular  array  or  list  elements.  The  character  is  used 
to  qualify  attribute  names.  Array,  List,  and  Set  elements  are  specified  by  enclosing  a numeric 
expression  within  square  brackets. 

Syntax 


148  ID  • ID-SIMPLE  I ID-QUALIFIED  . 

162  ID-SIMPLE  - LETTER  { ID-CHAR  } . 

140  ID-CHAR  - LETTER  I DIGIT  I UNDERSCORE  . 

151  ID-QUALIFIED  • ID-INDEIED  < DOT  ID-INDEIED  } . 
160  ID- INDEXED  - ID  < SUBSCRIPT  } . 

Example: 


Valid  Identifiers 


POINT  line  Circle  Rat ional.B .Spline 

itea406 


Valid  Qualified  Identifiers 


Point. X Z[i*2] 
Invalid  Identifiers 


underscore  can't  be  first  character 
? can't  be  part  of  identifier 
digit  can't  be  first  character 
schema  is  an  Express  keyword 


.POINT 

line? 

Sdcircle 

schema 


A. 5.1  Simple  Identifiers 

A simple  identifier  is  any  identifier  that  has  no  qualification. 
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A. 5. 2 Qualified  Identifiers 

Qualified  identifiers  must  be  used  when  it  is  impossible  to  determine  the  scope  of  a simple 
identifier  or  when  an  element  is  subscripted  as  in  an  array. 

Example: 


X - X ♦ y.c[37];  --  y.cCST]  is  a qnalilisd  identllier. 

Note  - See  the  Function  Call,  which  can  also  be  qualified. 

A. 5. 3 Scope  of  Identifiers 

A particular  kind  of  object  is  created  by  a declaration  of  an  identifier  at  some  place  in  a schema. 
When  that  identifier  is  used  again,  it  must  be  within  the  scope  of  its  declaration. 

The  scope  of  an  identifier  is  that  part  of  the  schema  in  which  a reference  to  an  identifier  refers 
to  the  same  object  the  declaration  created.  A scope  encompasses  its  declaration  to  the  end  of 
the  current  block,  including  all  blocks  declared  within  the  current  block. 

The  blocks  that  establish  a scope  in  this  manner  are: 

1.  Schema 

2.  Entity 
S.  Map 

4.  Function 

5.  Procedure 

6.  Rule 

An  identifier  can  be  redeclared  in  another  block.  That  is,  the  same  name  can  be  used  in  another 
context.  In  such  a case,  the  identifier  represents  some  entirely  different  thing  and  it  should  not 
be  confused  with  any  other  like  identifier.  A given  identifier  cannot  be  redeclared  within  the 
seime  block  however.  For  example,  if  there  is  an  entity  called  el  in  schema  si,  the  name  el 
cannot  be  redeclared  in  si  for  any  purpose. 

An  identifier  cannot  normally  be  seen  outside  its  scope.  The  Assiune  directive  can  be  xised  to 
overcome  this  restriction. 

Example: 

♦-  Universe  ------------- 

Built-in  Constants 

I Built-in  Functions  I 

Built-in  Procedures 
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Built-in  Type* 

♦-  Schema  SI  ------------------ 

I I 

I ♦-  Schema  S2-- | 

i I II 

I I ♦-  Entity  El ♦ I I 


I ♦-  Schema  S3  --------- — | 

II  III 

I I ♦-  Entity  E2  ------  | | 

I I I A2  : El  : I I I I El  cannot  be  seen  from  the 

I I 4 ♦ I I scope  established  by  schema  S3. 

II  III  Thus,  this  reference  is  illegal. 

I 4............. — --- — ..4  I 

4....... .......... ............4 
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l^be  outermost  achema  ( SI  ) exists  within  the  ” universe” , which  can  be  immagined  as  a schema 
that  encloses  every  other  schema.  All  of  the  built-in  constants,  types,  functions,  and  procedures 
can  be  thought  of  as  having  been  declared  within  the  universe.  As  a consequence,  those  built-in 
elements  can  be  referenced  from  anywhere. 

Entity  el  is  declared  in  the  scope  established  by  Schema  $2  and  entity  e£  is  declared  in  the 
scope  established  by  Schema  $S.  The  attribute  named  af  in  entity  ef  attempts  to  use  el  as  its 
type.  That  is  illegal  since  el  is  not  in  the  scope  of  $S. 

The  Assume  directive  can  be  used  to  cross  normal  scope  boundaries.  Had  Schema  S3  contained 
the  directive  "Assume  (S2);”  the  declarations  in  the  scope  of  S2  could  have  been  seen  within 
S3. 


A. 6 Literals 

A literal  is  a self  defining  constant  value.  The  type  of  a literal  depends  on  how  characters  are 
compx>8ed  to  form  a token.  The  literals  are  integer,  real,  string,  or  logical. 

A.6.1  Integer  Literal 

An  integer  literal  is  composed  entirely  of  digits.  It  defines  an  integer  (whole)  number. 

Syntax 
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155  INTEGER-LITERAL  • DIGIT  { DIGIT  } . 

Example: 


4016 

38 

A.6.2  Real  Literal 

A real  literal  ia  composed  of  a mantissa  and  an  optional  exponent.  It  defines  a fractional 
number. 

Syntax 


160  REAL-LITERAL  ■ INTEGER-LITERAL  DOT  [ INTEGER-LITERAL  ] [ 'E’  [ SIGN  ] 
INTEGER-LITERAL  ] . 

Example: 


l.e6 

3.5e-5 

350.62 

Illegal  Real  Literal 


.001  At  least  one  digit  aust  precede  the  deciaal  point 

lelO  A decinal  point  aust  be  part  of  the  literal 

A. 6. 3 String  Literal 

A string  literal  is  a sequence  of  characters  enclosed  by  quote  marks  (apostrophes).  If  a quote 
mark  is  itself  part  of  the  string,  two  consecutive  quote  marks  must  be  written.  A string  literal 
cannot  span  a physical  line. 

Syntax 


176  STRING-LITERAL  - \Q  { \A  I ( \Q  \Q  ) } \Q  . 

Note  - \a  represents  any  character  except  a newline;  \q  represents  a quote  mark. 
Example: 


'Baby  needs  a new  pair  of  shoes! ' 

Reads  ...  Baby  needs  a new  pair  of  shoes! 

'Ed’’s  Computer  Store' 

Reads  ...  Ed's  Computer  Store 
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Illegal  String  Literal 

'Ed's  Coaputcr  Store’ 

There  aast  always  be  an  ewen  nnaber  of  quote  aarks. 

A.6.4  Logical  Literal 

A logical  literal  is  any  of  the  words  Tyue’,  Talse’,  or  *Unknown\ 
Syntax 


160  LOGICiL-LITEEJLL  - TRUE  I FALSE  I UNKNOWN  . 


Example: 

X :■  true: 
y :■  false; 

z :■  unlaiown; 

A. 7 Directives 

The  compiler  directives  allow  the  schema  writer  to  control  the  behavior  of  the  compiler  that 
processes  an  Express  source  file.  The  Assume  directive  is  used  to  override  normal  scoping 
rules.  Define  directives  allow  identifiers  to  stand  for  a substitution  string.  The  Export 
directive  allows  a schema  to  control  what  may  or  may  not  be  seen  outside  its  scope.  Include 
directives  allow  separate  source  to  be  combined  into  a single  logical  file.  The  Uses  directive 
allows  individual  declarations  in  some  other  schema  to  be  used  as  if  they  are  part  of  another 
schema. 


A. 7.1  Assume  Directive 

Description: 

The  Assume  directive  is  used  to  gain  access  to  declarations  that  are  not  normally  known  via 
ordinary  scoping  rules.  The  directive  specifies  one  or  more  schema  names.  When  an  identifier 
reference  is  unresolved,  an  attempt  will  be  made  to  resolve  that  identifier  in  the  schemas  men- 
tioned by  the  Assume  directive. 

Note  that  the  author  of  a schema  can  use  the  Export  directive  to  prevent  other  schemas  &om 
using  an  identifier,  even  when  the  other  schema  uses  the  Assume  directive. 

Syntax 

184  ASSUME -DIRECTIVE  • ASSUME  LEFT-PAREN  SCHEMA-ID  { COMMA  SCHEMA-ID  } 
RIGHT-PAREN  SEMICOLON  . 
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Example: 

See  the  example  ^ven  in  6.3.  (Export  Directive). 

Restrictions: 

• The  ASSUME  directive  must  appear  before  any  identifier  references  that  require  the  as- 
sumed schemas  to  resolve  those  identifiers. 

A. 7.2  Define  Directive 
Description: 

A lexical  constant  is  created  by  the  Define  directive.  It  equates  an  identifier  to  a sequence 
of  characters  which  must  be  enclosed  by  quotes.  Whenever  this  lexical  constant  identifier 
is  encountered,  the  sequence  of  characters  equated  to  it  are  substituted  in  its  place.  The 
substitution  can  consist  of  sero  or  more  characters. 

Syntax 


103  DEFINE-DIRECTIVE  - DEFINE  DEFINED-TYPE-ID  STRING -LITERAL  SEMICOLON  . 
Example: 


DEFINE  auchprecision  ’R£AL(30)'; 

Whenever  the  identifier  muchprecision  is  seen  in  the  source  file  the  character  string  REAL(30) 
is  substituted  for  it.  The  enclosing  quotes  are  not  part  of  the  substitution  and  the  substitution 
can  consist  of  zero  or  more  characters.  Thus  if  the  following  line  appeared  in  the  schema: 


X : auchprecision  ; 


the  line  would  be  interpreted  as: 

X : REAL (30)  ; 

A substitution  string  can  contain  other  defined  lexical  constants  as  in: 

DEFINE  a *30’; 

DEFINE  b 'real (a) ' ; 


then 


X : b; 
yields : 
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X : real (30) ; 


Rettrictions: 


• A Define  directive  must  appear  before  a reference  to  a reference  to  the  identifier. 

• Circular  defines  are  prohibited.  If  substitution  string  A reference  identifier  B,  then  sub- 
stitution string  B cannot  reference  identifier  A either  directly  or  indirectly. 

A. 7.3  Export  Directive 
Description: 

The  Export  directive  is  used  to  allow  access  to  objects  declared  within  a schema.  If  a schema 
does  not  supply  an  Export  directive,  nothing  can  be  exported;  i.e.,  seen  outside  its  scope. 

Syntax 


46  EXPORT  • ’EXPORT*  . 
Restrictions: 


1.  Indirect  declarations  cannot  be  exported.  For  example,  a function  declared  within  a 
function  cannot  be  exported  in  this  manner. 

Example: 

The  following  example  shows  how  the  Export  and  Assume  directives  work  together.  The  schema 
called  main  encompasses  two  inner  schemas:  insidel  and  mside2.  Some  of  the  declarations  in 
insidel  are  private  and  others  are  public  (exported).  Declarations  in  inside2  reference  entities 
declared  in  insidel. 


SCHEMA  MAIN; 

ENTITY  X:  < ♦ 

END .ENTITY:  I 

SCHEMA  INSIDEl;  I 

EXPORT  (111.  112):  I 

ENTITY  111;  < ♦ I 

END .ENTITY.  I I 

ENTITY  112;  I I 

END.ENTITY.  I I 

ENTITY  113;  < ♦ I I 

END.ENTITY.  I I I 

END .SCHEMA;  I I I 
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SCHEMA  INSIDE2:  | 

ASSUME  (INSIDEl):  | 

ENTITY  121:  I 

A : I;  (1) 

END .ENTITY;  | 

ENTITY  122;  | 

A : 113;  (2) ♦ 

END .ENTITY; 

ENTITY  123; 

A : 111;  (3) 

END .ENTITY; 

END.SCHEMA; 

END .SCHEMA; 

• The  reference  to  (entity)  X is  resolved  according  to  normal  scoping  niles. 

• The  reference  to  (entity)  113  is  ILLEGAL!  Even  though  113  is  declared  within  INSIDEl, 
which  is  assumed,  113  was  not  marked  as  exportable;  i.e.,  it  is  private. 

• The  reference  to  (entity)  111  is  resolved  correctly.  INSIDEl  is  assumed  and  113  was  marked 
as  exported. 

A. 7. 4 Include  Directive 
Description: 


A schema  can  be  made  up  of  several  separate  source  files.  These  files  can  be  composed  into  a 
single  logical  source  file  by  the  use  of  the  Include  directive.  Whenever  the  Include  directive  is 
encountered,  the  file  specified  is  processed  just  as  if  it  were  physically  present  in  the  file  in  which 
the  Include  appears.  Includes  can  be  nested  to  the  depth  permitted  by  the  operating  system 
environment.  The  form  of  the  file  name  specification  is  also  dependent  on  the  operating  system. 

Syntax 


216  INCLDDE-DIRECTIVE  • INCLUDE  STRING -LITERAL  SEMICOLON  . 
Example: 


SCHEMA  abc; 

INCLUDE  ’partl.dat'; 

INCLUDE  •part2.dat*; 

END.SCHEMA: 

The  schema  named  abc  is  composed  of  three  separate  files;  the  schema  itself  and  the  files  named 
partl.dat  and  part2.dat. 

Restrictions: 
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• Circular  includes  are  prohibited.  If  file  A includes  file  B,  then  file  B must  not  include  file 
A either  directly  or  indirectly. 

• The  file  name  is  operating  system  dependent. 

A. 7. 5 Uses  Directive 
Description: 

The  Uses  directive  creates  an  exact  logical  copy  of  the  objects  listed.  In  effect,  those  objects 
become  part  of  the  current  schema.  The  main  use  of  the  Uses  directive  is  to  define  application 
aubset  schemas. 

Syntax 


265  USES -DIRECTIVE  - USES  NESTED- ID-LIST  SEMICOLON  . 
Restrictions: 


• A schema  cannot  appear  as  an  identifier  in  a Uses  directive. 

Example: 

An  application  subset  schema  defines  several  entities  unique  to  it,  and  also  brings  in  several 
other  entities  declared  elsewhere.  The  Uses  directive  is  required  since  none  of  the  declarations 
within  the  ^plication  subset  reference  those  entities  either  directly  or  indirectly. 


SCHEMA  MAIN; 

--  A THRU  G ARE  DECLARED  HERE. 

SCHEMA  APPLICATION.SUBSET; 

USES  (A.  B.  C.  D.  E.  F.  G) ; 

ENTITY  H; 

END.ENTITY: 

ENTITY  J; 

END.ENTITY; 

END.SCHEMA; 

END.SCHEMA; 

The  schema  named  applicationjubset  declares  the  entities  H and  J.  It  also  needs  to  treat 
entities  A through  G as  if  they  were  part  of  the  schema.  When  an  implementation  of  the 
application  subset  is  developed,  it  needs  only  to  account  for  the  entities  defined  in  the  applica- 
tion subset  schema,  and  entities  defined  elsewhere  but  referenced  from  it.  The  Uses  directive 
creates  a logical  declaration  of  entities  of  interest. 
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A. 8 Types 

Types  are  used  to  associate  a data  representation  with  an  attribute,  local  variable,  or  formal 
parameter. 

Syntax 


type 

• base-type 
I aggregation-type 
I entity-type 
I delined-type 
I Buaber-type 
I enuaeration-type 
I select-type 
I generic -type 


A. 8.1  Base  Types 

Description 

The  base  types  represent  the  data  values  that  can  be  held  in  an  information  system  of  some 
kind.  Tracing  a path  through  the  schema  will  eventually  end  with  one  of  these  base  types.  The 
base  types  are  Real  Integer  String  and  Logical. 

Syntax 


186  BASE-TYPE  - INTEGER-TYPE  I LOGICAL-TYPE  I NUMBER-TYPE  I REAL-TYPE 
I STRING-TYPE  . ^ 

220  INTEGER-TYPE  ■ INTEGER  [ PRECISION-SPEC  ] . 

233  PRECISION-SPEC  - LEFT-PAREN  EXPRESSION  RIGHT-PAREN  . 

227  LOGICAL-TYPE  - LOGICAL  . 

231  NUMBER-TYPE  - NUMBER  . 

237  REAL-TYPE  - REAL  [ PRECIS ION- SPEC  ] . 

252  STRING-TYPE  - STRING  [ PRECISION-SPEC  ] [ VARYING  ] . 


A. 8. 1.1  Integer  Type 
Description 

An  Integer  type  represents  a whole  number.  You  can  optionally  specify  the  maximum  number 
of  decimal  digits.  If  the  number  of  decimal  digits  is  given,  there  is  an  implicit  constraint  on 
the  value.  For  example,  the  specifeation  *INTEGER(3)”  would  constrain  a value  to  -999. ..999 
inclusive.  The  value  of  the  integer  number  is  unconstrained  if  no  precision  specification  is  given 
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The  number  of  decimal  digits  specified  suggests  the  storage  allocation  needed  to  hold  a value  of 
that  type;  e.g.,  if  a signed  binary  two’s  complement  internal  representation  is  used,  the  formula 
h=(preeision/0.S010$)  yields  the  approximate  number  of  bits  needed. 

Syntax 


220  INTEGER-TYPE  ■ INTEGER  [ PRECISION-SPEC  ] . 

233  PRECISION-SPEC  - LEFT-PAREN  EXPRESSION  RIGET-PAREN  . 


Rules  and  Restrictions: 

• ezpresnon  must  yield  a numeric  mult  that  is  non>tero  and  non-negative. 

• A real  result  is  truncated  to  an  integer. 

Example: 

This  example  associates  an  integer  type  with  the  attribute  named  AGE  JN .YEARS.  The  value 
of  the  integer  is  totally  unconstrained. 

ENTITY  PERSON; 

AGE.IN.YEARS  : INTEGER; 

END .ENTITY; 

Operations  on  Integer  Types: 


1 fora 

1 

op  1 

description 

1 

1 nnary 

1 

4 1 

no  ellect 

1 

1 nnary 

1 

- 1 

negates  the  operand 

1 

1 binary 

1 

4 1 

loms  the  snn  ol  the  operands 

1 

I binary 

1 

- 1 

forms  the  difference  of  the  operands 

1 

1 binary 

1 

* 1 

forms  the  product  of  the  operands 

1 

1 binary 

1 

/ 1 

converts  operands  to  real  and  forms  real  quotient 

1 

1 binary 

1 

div  1 

forms  integer  quotient 

1 

1 binary 

1 

■od  1 

forms  integer  modulus 

1 

1 binary 

1 

**  1 

raises  opl  to  the  power  op2 

1 

1 binary 

1 

m 1 

compares  for  equality 

1 

1 binary 

1 

<>  1 

compares  for  inequality 

1 

1 binary 

1 

< 1 

compares  for  less  than 

1 

1 binary 

1 

<■  1 

compares  for  less  than  or  equal 

1 

1 binary 

1 

> 1 

compares  for  greater  than 

1 

1 binary 

1 

>■  1 

compares  for  greater  than  or  equal 

1 

4 + 
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A. 8. 1.2  Real  Type 

DeBcription 

A Real  type  represents  & normalized  fractional  number.  A real  is  sometimes  called  a Boat, 
a floating  point  number,  or  scientiflc  notation.  It  has  an  inexact  resolution.  The  number  of 
significant  decimal  digits  can  optionally  be  specified.  The  precision  of  the  real  number  is  ud> 
constrained  if  no  precision  specification  is  given. 

The  number  of  decimal  digits  specified  suggests  the  storage  allocation  needed  to  hold  a value  of 
that  type;  e.g.,  if  a signed  binary  two’s  complement  internal  representation  is  used,  the  formula 
h=(preeuion/0.S010S)  yields  the  approximate  number  of  bits  needed  for  the  mantissa.  It  also 
suggests  the  maximum  number  of  digits  that  are  transmitted  in  the  physical  file. 

Syntax 


237  R£AL‘TTPE  - REAL  [ PRECISION- SPEC  ] . 

233  PRECISION-SPEC  - LEFT-PAREN  EXPRESSION  RIGHT-PAREN  . 

Rules  and  Restrictions: 


• ezprestion  must  yield  a numeric  result  that  is  non-zero  and  non-negative. 

• A real  result  is  truncated  to  an  integer. 

Example: 

This  exzkmple  shows  the  effect  of  defining  the  number  of  decimal  digits  in  the  fraction  part  of 
a real  number;  i.e,  it’s  precision. 

LOCAL 


DISTANCE 

REALCe) ; 

11.  Yl.  Z1  : 

REAL; 

12.  Y2.  Z2  : 

REAL; 

END.LOCAL: 

11  :•  0:  Yl 

0;  Z1  : 

12  10;  Y2 

:•  11;  Z2 

DISTANCE  :•  SQRT((I2-I1)**2  ♦ (Y2-Y1)**2  ♦ (Z2-Z1)**2): 

DISTANCE  is  computed  to  a value  of  1.9104973. ..e-f-1  but  has  an  actual  value  of  1.91050e-rl 
since  the  specification  calls  for  six  digits  of  precision;  thus,  only  six  normalized  digits  of  preci- 
sion are  retained. 

Rounding  is  performed  as  follows:  given  p which  is  the  precision,  the  digit  at  p-hl  is  examined. 
If  that  digit  is  five  or  more,  one  is  added  to  the  digit  p. 
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When  two  re&l  numbers  axe  compared,  the  one  with  the  smaller  precision  is  tero  extended  to 
match  the  longer  specification.  For  example,  given: 


i : E£iL(3)  1.23E0: 

B : R£iL(5)  1.2300E0; 

the  expression  {\tt  (a"b)}  will  be  true. 

Operations  on  Real  Types: 


fora 

1 

op  1 

description 

unary 

1 

4 1 

no  effect 

nnary 

1 

- 1 

negates  the  operand 

binary 

1 

4 1 

foms  the  sna  of  the  operands 

binary 

1 

- 1 

foras  the  difference  of  the  operands 

binary 

1 

m 1 

foras  the  product  of  the  operands 

binary 

1 

/ 1 

foras  real  quotient 

binary 

1 

1 

div  1 

1 

converts  operands  to  integer  and  foras  integer 
quotient 

binary 

1 

1 

■od  1 

1 

converts  operands  to  integer  and  foras  integer 
Bodulus 

binary 

1 

**  1 

raises  opl  to  the  power  op2 

binary 

1 

m 1 

coapares  for  equality 

binary 

1 

<>  1 

coapares  for  inequality 

binary 

1 

< 1 

compares  for  less  than 

binary 

1 

<■  1 

coapares  for  less  than  or  equal 

binary 

1 

> 1 

coapares  for  greater  than 

binary 

1 

>■  1 

coapares  for  greater  than  or  equal 

Normalization 

A non-zero  real  number  is  normalized  in  the  following  manner.  Reading  from  left  to  right,  find 
the  first  significant  (i.e.,  non-zero)  digit.  Then  adjust  the  decimal  point  so  that  it  lies  just  to 
the  right  of  the  significant  digit.  Count  the  number  of  places  the  decimal  point  moved  and  the 
direction  it  moved.  If  it  moved  to  the  right,  subtract  one  from  the  exponent  for  each  position; 
if  it  moved  to  the  left,  add  to  the  exponent. 

Example: 


0.0  0.0 

O.OOOOOlell  l.OeB 

00017800000. eO  1.78e+7 


A. 8. 1.3  Logical  Type 
Description 
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A Logical  type  represents  a True/False  value.  Uxilmown  is  a third  logic  state  which  can 
be  used  when  the  state  of  a logical  value  is  neither  TVue  nor  False. 

The  following  conditions  hold  for  logical  types: 

False  < Unknown  < True 


Symtax 


227  LOGICAL-TTPE  - LOGICAL  . 


Example: 

This  example  associates  a logical  type  with  an  attribute  named  FLAG.  FLAG  can  only  hold 
the  values  True  and  False. 

ENTITT  SOMETHING; 

FLAG  : LOGICAL; 

END .ENTITY; 

Operations  on  Logical  Types: 


lorn  1 

op  1 

description 

P 

unary  1 

not  1 

reverses  the  state  of  the  operand 

P 

binary  I 

and  1 

returns  true  iT  both  operands  are  true 

1 

binary  1 

or  1 

returns  true  if  either  operand  is  true 

1 

binary  1 

xor  1 

returns  true  if  one  of  the  operand  is  true 

F 

binary  1 

■ 1 

coapares  lor  equality 

1 

binary  1 

<>  1 

compares  lor  inequality 

I 

binary  I 

< 1 

compares  lor  less  than 

F 

binary  1 

<•  1 

compares  lor  less  than  or  equal 

t 

binary  1 

> 1 

compares  lor  greater  than 

1 

binary  I 

>■  1 

compares  lor  greater  than  or  equal 

F 

^nth  Tables 


AND 

T I ? I F 

.4. 

T I T I ? I F I 


OR 

T I ? I F 

4 4 

T I T I T I T I 


NOT 

4 4 

1 T I F I 
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♦ * 

? I ? I ? I F I 

F I F I F I F I 

A.8.1.4  String  Type 

Description 

A String  type  represents  & sequence  of  zero  or  more  ch&racters.  The  character  set  and  collating 
sequence  is  defined  by  ISO  6937/2. 

Characters  and  symbols  not  defined  by  that  standard  can  be  represented  as  an  "escape”  se- 
quence. The  escape  sequence  is  defined  in  normative  Annex  B,  the  Physical  File  Structure 
Language.  An  example  of  an  ^ape  sequence  is  given  below. 

The  maximum  number  of  characters  in  a string  can  be  specified.  If  no  such  specification  is 
given,  the  maximum  length  of  the  string  is  unlimited. 

The  varying  property  indicates  that  the  string  is  allowed  to  grow  and  shrink  in  apparent  size. 
The  absence  of  the  varying  property  indicates  that  the  string  is  always  exactly  the  specified 
size. 

Syntax 


4 4---4-..4  4,.  — 4---4 

TITITITI  |?|?| 

4. . .4. ..4. ..4  4. ..4. ..4 

FITI7IFI  IFITI 

4.. .4...4.._4  4...4»«-4 


252  STRING-TTPE  ■ STRING  [ PRECISION-SPEC  ] [ VIRTING  ] . 
233  PRECISION-SPEC  • LEFT-PAREN  EXPRESSION  RIGHT-PAREN  . 

Rxiles  and  Restrictions: 


• expression  must  yield  a numeric  result  that  is  non-zero  and  non-negative. 

• A real  result  is  truncated  to  an  integer. 

Example: 

The  following  four  examples  show  the  effect  of  the  different  specification  elements  of  a string. 
STRINGl  : STRING; 

This  defines  an  abstract  string.  It  cannot  be  implemented  without  making  assumptions  about 
its  maximum  length. 

STRING2  : STRING(IO) ; 

This  defines  a string  that  is  always  ten  characters  in  length;  i.e.,  all  ten  positions  are  assumed 
to  hold  a character  of  some  kind. 
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STRINGS  : STRING  VARYING ; 

This  defines  &n  abstract  string.  It  cannot  be  implemented  without  making  assumptions  about 
its  maximum  length. 

STRING4  : STRING (10)  VARYING; 

This  defines  a string  that  can  hold  aero  to  ten  characters. 

Escape  Sequence  Example: 


letters  :■  *lgreek:01.  02,  03! ABCIaathSiOl . 02,  031 *; 

The  string  in  this  example  has  nine  characters  and  uses  characters  from  three  character  sets. 
The  first  three  come  from  the  Greek  character  set,  the  next  three  come  from  the  (default)  ISO 
6937/2  set,  and  the  last  three  come  from  a math  character  set.  The  numbers  (01,  02,  etc.)  refer 
to  a specific  character  in  the  designated  character  set. 

Operations  on  String  Types: 


Yora  1 

op  1 

description 

binary 

II  1 

concatenates 

the  operands 

binary 

■ 1 

coapares  lor 

equality 

binary 

<>  1 

coapares  lor 

inequality 

binary 

< 1 

coapares  lor 

less  than 

binary 

<■  1 

coapares  lor 

less  than  or  equal 

binary 

> 1 

coapares  lor 

greater  than 

binary 

>■  1 

coapares  lor 

greater  than  or  equal 

binary 

like  1 

returns  true 

il  the  lelt  operand  Batches  the 

1 

teaplate,  which  is  the  right  operand 

♦ 

I 

4 


4- 


Components  of  a string  variable  can  be  addressed  by  a subscript.  For  example,  the  seventh 
character  of  a string  called  "name”  could  be  examined  by 

IF  NAME[7]-’S‘  THEN 


String  comparison 

To  compare  two  strings,  compare  the  first  (leftmost)  pair  of  characters,  then  the  pair  at  the 
second  position,  etc.  until  an  unequal  pair  is  found,  or  until  all  character  pairs  have  been 
examined.  If  an  unequal  pair  is  found,  the  string  containing  the  lesser  character  (as  defined  by 
the  ISO  6937/2  collating  sequence)  is  considered  less  than  the  other  string.  When  all  pairs  are 
equal,  the  two  strings  are  equal. 


27 


N287 


When  two  strings  sxe  not  the  s&me  length,  the  shorter  siring  is  blank  extended  until  the  lengths 
of  the  two  strings  are  the  same. 

Implementations  that  do  not  use  the  ISO  6937/2  collating  sequence  must  yield  a string  com- 
parison re8;ilt  that  is  the  same  as  an  implementation  that  does. 


A.8.3  Aggregation  Types 
Description 

Aggregation  types  are  used  to  represent  ordered  or  unordered  collections  of  like  things.  These 
collections  can  have  fixed  or  varying  sizes.  Aggregation  types  are  called  Aggregate,  Array  List 
and  Set. 

Syntax 


181  AGGREGATION-TYPE  - AGGREGATE -TYPE  I ARRAY-TYPE  I LIST-TYPE  I SET-TYPE  . 
180  AGGREGATE-TYPE  • AGGREGATE  LIMIT-SPEC  OF  [ UNIQUE  ] ATTRIBUTE -CAN -BE  . 

222  LIMIT-SPEC  • LEFT-BRACKET  EXPRESSION  COLON  ( EXPRESSION  I INFINITY  ) 
RIGHT-BRACKET  . 

182  ARRAY-TYPE  ■ ARRAY  INDEX-SPEC  OF  [ OPTIONAL  ] [ UNIQUE  ] 
ATTRIBUTE-CAN-BE  . 

218  INDEX-SPEC  - LEFT-BRACKET  EXPRESSION  COLON  EXPRESSION  RIGHT-BRACKET  . 

223  LIST-TYPE  - LIST  LIMIT-SPEC  OF  [ UNIQUE  ] ATTRIBUTE-CAN-BE  . 

247  SET-TYPE  - SET  [ LIMIT-SPEC  ] OF  ATTRIBUTE-CAN-BE  . 

A. 8. 2.1  Aggregate  Type 
Description 


An  Aggregate  type  is  a generalization  of  any  aggregation  type;  i.e.,  an  Array,  List,  or  Set.  An 
aggregate  type  can  be  used  only  as  a formal  parameter  of  a function  or  procedure,  or  as  the 
result  of  a function. 


When  a procedure  or  function  is  invoked,  an  actual  parameter  is  passed.  That  actual  parameter 
must  be  either  an  Array,  List,  or  Set.  The  operations  that  can  be  performed  then  depend  on 
the  type  of  the  actual  parameter. 

Syntax 


180  AGGREGATE- TYPE  • AGGREGATE  LIMIT-SPEC  OF  [ UNIQUE  ] ATTRIBUTE-CAN-BE  . 
222  LIMIT-SPEC  • LEFT-BRACKET  EXPRESSION  COLON  ( EXPRESSION  I INFINITY  ) 
BIGHT-BRACKET  . 

Rules  and  Restrictions: 


• Both  expressions  must  yield  a number  result. 
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• A reaJ  result  is  truncated  to  an  integer. 

• Expression!  is  the  lower  bound  of  the  array. 

• Expres8ion2  is  the  upper  bound  of  the  array. 

• The  lower  bound  must  be  less  than  or  equal  to  the  upper  bound. 

• The  Optional  specification  indicates  that  the  array  instance  can  be  sparse;  i.e.,  all  of  the 
elements  are  not  always  populated. 

• The  Unique  specification  mdicates  that  each  populated  element  of  an  array  must  be 
different  than  all  other  populated  elements. 

Example: 

This  example  shows  how  a multi-dimensioned  array  is  declared. 

sectors  : ARiUY  [ 1 : 10  ] OF  ARRAY  [ 11  : 14  ] OF  e; 

The  first  array  has  10  elements  of  type  ARRAY(ll;14]  OF  e.  There  are  40  elements  total  in 
the  attribute  named  sectors.  There  is  no  restriction  on  the  number  of  dimensions  of  an  array. 
Operations  on  Array  Types: 


lorn  1 

op  1 

description 

binary  I 

• 1 

coopares  for  equality 

binary  1 

<>  1 

compares  lor  inequality 

A. 8. 2. 2 List  Type 

Description 

A List  type  represents  an  ordered  collection  of  like  elements.  The  number  of  elements  of  a list 
can  vary  from  one  occurrence  to  another.  A list  specifies  the  minimum  number  of  elements  that 
must  be  present  and  the  maximum  number  of  elements  that  can  be  present.  The  minimum 
bound  of  a list  must  never  be  less  than  zero  and  the  maximum  bound  can  be  either  exact  or 
indefinite.  The  number  of  elements  in  a list  can  vary  between  the  minimum  and  maximum 
bounds  (inclusive). 

The  SixeOf  built-in  function  can  be  used  to  determine  the  number  of  elements  in  a list. 
Syntax 


223  LIST-TYPE  • LIST  LIMIT-SPEC  OF  [ UNIQUE  ] ATTRIBUTE -CAN -BE  . 

222  LIMIT-SPEC  • LEFT-BRACKET  EXPRESSION  COLON  ( EXPRESSION  I INFINITY  ) 
RIGHT-BRACKET  . 
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Rules  and  Restrictions: 


1.  Both  expressions  must  yield  a number  result. 

2.  A real  result  is  truncated  to  an  integer. 

8.  Expressionl  is  the  minimum  number  of  elements  that  must  be  in  a list. 

4.  Expre8sion2  is  the  maximum  number  of  elements  that  can  be  in  a list.  The  alternate  # 
specification  states  that  the  size  of  the  list  is  unconstrained. 

5.  The  lower  bound  must  be  less  than  or  equal  to  the  upper  bound  and  it  must  be  non- 
negative. 

6.  The  Unique  specification  indicates  that  each  element  of  a list  must  be  different  than  all 
other  elements.  The  effect  of  using  unique  in  the  declaration  of  a list  is  to  define  an 
ordered  set. 

Example: 

This  example  defines  a list  of  arrays.  The  list  can  contain  zero  to  ten  arrays.  Each  array  must 
be  different  from  all  other  arrays  in  the  list. 

ConplexList  : LIST [0:10]  OF  UNIQUE  ARRATClilO]  OF  INTEGER; 

There  are  zero,  10,  20,  ...,  100  integer  values  associated  with  the  attribute  named  ComplexList 
depending  on  the  number  of  list  elements.  Each  array  must  be  different  than  every  other  array 
as  specified  by  the  Unique  qualifier. 

Operations  on  List  Types: 


4.. ............................................ ............. + 

I loro  1 op  I description  I 

4..  .................................................... 4 

I binary  I ■ I coapares  lor  equality  I 

I binary  i <>  I coapares  lor  inequality  I 

I binary  I in  I returns  true  11  the  lirst  operand  (an  eleaent  ol  I 

I I I the  list)  is  in  the  list  I 

I binary  I * i L<*'E  adds  E to  end  ol  list  I 

I I I E-t-L  adds  E to  Iront  ol  list  I 

I I I combines  the  two  lists  (concatenation)  I 

4 


L represents  a list;  E represents  an  element  ol  that  list. 
The  INSERT  built-in  procedure  is  used  to  insert  elements  into  a list. 
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A. 8. 2. 3 Set  Type 
DescriptioQ 

A Set  type  represents  an  unordered  eollection  of  like  elements.  The  number  of  elements  in  a 
set  can  be  constrained,  but  that  is  not  nectary;  it  can  be  empty  or  contain  any  number  of 
elements.  No  two  elements  of  a set  can  have  the  same  value  however. 

Syntax 


247  gET-TTPE  • SET  [ LIMIT-SPEC  ] OF  ATTSIBUTE-CAN-BE  . 

222  LIMIT-SPEC  ■ LEFT-BRACKET  EXPRESSION  COLON  ( EXPRESSION  I INFINITY  ) RIGHT-BRA( 


Hules  and  Restrictions: 


• Both  expr^ions  must  yield  a number  result. 

• A real  r^ult  is  truncated  to  an  integer. 

• Expression!  is  the  minimum  number  of  elements  that  must  be  in  a set. 

• Expression2  is  the  maximum  number  of  elements  that  can  be  in  a set.  The  alternate  # 
specification  states  that  the  sue  of  the  set  is  unconstrained. 

• The  lower  bound  must  be  less  than  or  equal  to  the  upper  bound  and  it  must  be  non- 
negative. 

Example: 

This  example  defines  an  attribute  as  a set  of  points  (an  entity  type). 

ABunchOf Points  : Set  01  Point; 

The  attribute  named  ABunchOlPoints  can  contain  zero  or  more  points.  Each  point  instance 
(in  the  set  instance)  must  be  different  than  every  other  point  in  the  set. 

If  a set  requires  at  least  one  (or  more)  element,  the  specification  can  provide  a lower  bound. 
ABunchOlPoints  : Set  [1:#]  01  Point; 

The  attribute  named  ABunchOfPoints  now  must  contain  at  least  one  point.  Each  point  in- 
stance (in  the  set  instance)  must  be  different  than  every  other  point  in  the  set. 

Operations  on  Set  Types: 


I lorn  I op  I description 
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binary 

1 

■ 

binary 

1 

<> 

binary 

1 

1 

in 

binary 

1 

1 

♦ 

binary 

1 

♦ 

binary 

1 

- 

binary 

1 

- 

binary 

1 

• 

binary 

1 

<■ 

binary 

1 

>• 

coBp«xts  lor  oquAlity 
coBpATtt  lor  inequality 

returuj  true  il  the  lirat  operand  (an  element  ol 
the  set)  is  in  the  set  (E  in  S) 

64S  is  union 
S**-£  adds  E to  S 
8*S  is  dillerence 
S-E  reaoTts  E Irou  S 
S*S  is  intersection 

returns  true  when  SI  is  a subset  ol  S2 
returns  true  when  S2  is  a subset  ol  SI 


S represents  a set;  E represents  an  eleaent  ol  that  set. 

A. 8. 3 Entity  Type 

Description 

Any  Entity  declared  in  a schema  can  be  used  as  the  type  of  an  attribute,  local  variable,  or 
parameter. 

Syntax 


200  EKTITY-TTPE  • ENTITY- ID  . 


B.ules  and  Restrictions: 


1.  An  entity  type  cannot  be  used  in  a defined  type. 

Example: 

This  example  uses  a Point  entity  as  the  type  of  an  attribute. 

ENTITY  POINT; 

I,  Y.  Z : REAL; 

END.ENTITY; 

ENTITY  LINE; 

PO.  PI  : POINT; 

END.ENTITY; 

The  line  entity  has  two  attributes  named  PO  and  Pi.  The  type  of  each  of  those  attributes  is 
[entity]  Point.  In  this  case  the  value  of  each  Point  is  mandatory.  Thus,  a line  cannot  exist 
without  those  two  points. 

Relationships  in  Express 
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Every  attribute  establishes  a relationship  between  an  entity  and  some  object.  That  object  can 
be  a terminal  or  a non>terminal  object.  A terminal  object  is  anything  such  as  an  integer  number 
that  we  think  of  as  irreducible.  The  base  types  of  Express  are  terminal  objects.  An  entity  is  a 
non-terminal  object.  The  nature  of  the  relationship  does  not  depend  on  whether  the  object  is 
terminal  or  non-terminal. 

Given  an  entity  E an  attribute  A and  the  type  of  the  attribute  T a relationship  can  be  dia- 
grammed as: 

E.i  ---[iin] [p:q]--->  T 

The  relationship  can  be  explained  in  English  as:  * T plays  the  role  of  A in  the  definition  of  E 
*.  For  example,  for  E=Line  A=Start  and  T=Point  the  interpretation  is:  * Point  plays  the  role 
of  Start  in  the  definition  of  Line  *. 

m and  n define  the  number  of  T’s  needed  for  each  E.A  ; p and  q define  the  number  of  E’s 
needed  for  each  T . 

The  value  of  m and  n is  specified  by  array,  list,  or  set  or  the  absence  of  one  of  those  aggregates. 
A specification  such  as 

A : B; 

means  that  m=n=l  while  the  specification 
A : ARJUTCl:00]  OF  B; 
translates  to  m=l:n:r90. 

The  value  of  p and  q depends  on  whether  the  relationship  is  internal  or  external.  An  internal 
relationship  always  yields  p=q=l\  i.e.,  for  every  T there  must  be  exactly  one  E.  An  external 
relationship  always  yields  p=0:q—^]  i.e.,  for  every  T there  can  be  sero  or  more  E’s.  Since 
dynamic  means  either  internal  or  external,  the  values  of  p and  q depend  on  whether  T is 
actually  interna]  or  external  in  an  entity  instance. 

In  a system  of  instances  (as  in  a database)  we  may  find  that  a constraint  has  to  be  put  on  p 
and  q.  In  other  words,  p=0:q=#  is  unacceptable.  The  cardinality  relational  operator  can  be 
used  to  state  that  constraint.  The  cardinality  relational  operator  looks  like 

T {\em  [ p*  : q’  ]}  E.A 

which  means  that  the  actual  number  of  E.A ’s  for  a given  T (A)  must  satisfy 
{ p’  <■  k <•  q'  } . 

We  have  not  redefined  p and  q,  but  have  constrained  k in  some  context  of  use. 

Operations  on  Entity  Types: 


form  1 

op  1 

description 

binary  I 

■ 1 

compares  for  equality 

binary  1 

<>  1 

compares  for  inequality 

binary  1 

:•:  1 

compares  for  instance  equality 

binary  I 

:<>:  1 

compares  for  Instance  inequality 
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A. 8.4  Defined  Type 
Description 

A Defined  type  is  s user  extension  to  the  set  of  built-in  types.  Defined  types  must  be  declared 
in  s Type  block.  Once  declared,  a defined  type  can  be  used  as  any  other  type. 

Entmieration  and  Select  types  can  be  defined  only  as  a defined  type. 

Syntax 

104  DEFINED-TTPE  • DEFINZD-TTPE-ID  . 

Rules  and  Restrictions: 


1.  A defined  type  must  be  declared  in  a Type... End. Type  block. 

2.  An  Entity  type  can  not  be  used  as  a defined  type. 

Example: 


Several  types  are  defined  below  to  indicate  the  units  of  measure  associated  with  certain  kinds 
of  attributes. 


TYPE 


AREA 

• 

REAL 

MAGNITUDE 

m 

REAL 

VOLUME 

m 

REAL 

MASS 

m 

REAL 

END .TYPE: 

ENTITY  PART; 


WEIGHT  : MASS; 

END .ENTITY; 

The  WEIGHT  attribute  is  represented  as  a real  number,  but  the  use  of  the  defined  type,  MASS, 
helps  to  clarify  the  meaning  and  context  of  the  real  number;  it  means  mass,  not  volume  or  area 
for  instance. 


Operations  on  Defined  Types: 

The  operations  applicable  to  defined  types  depends  on  the  base  type;  e.g.,  if  the  base  type 
is  real,  only  the  operation  set  for  real  types  can  be  used.  Note  however  that  assignment  of 
dissimilar  user  defined  types  is  restricted;  e.g.,  if  VA  is  a variable  of  type  A and  VB  is  a variable 
of  type  B then  the  statement  VA  :=  VB;  is  illegal. 
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A. 8. 5 Number  Type 
Description 

A Number  is  an  abstraction  of  Real  or  Integer  types.  Generally  speaking,  a number  type  is 
used  in  an  "abstract”  sense  when  an  exact  representation  does  not  matter,  or  as  the  specihca- 
tion  of  a generic  number  parameter  of  a function  or  procedure. 

Syntax 


231  KUMBER-TTPE  - KUMBER  . 

Example: 

The  following  example  shows  a generic  numeric  addition  function  that  accepts  any  number  as 
actual  parameters  and  returns  the  appropriate  kind  of  numeric  result.  An  integer  is  returned 
if  both  inputs  are  integers;  a real  result  is  returned  for  mixed  arithmetic.  This  function  does 
no  error  checking. 


FUNCTION  ADD ( A. B: NUMBER)  .-NUMBER; 
LOCAL 

RI  : INTEGER:  --  INTEGER  RESULT 
RR  : REAL;  --  REAL  RESULT 
END.LOCAL: 

CASE  TYPEOFCA)  OF 
INTEGER 


^£AL 


CASE  TYPEOFCB)  OF 
INTEGER  . BEGIN; 

RI 

:■  A+B; 

RETURN (RI) : 

END; 

REAL 

ojlGIN; 

RR 

A+B; 

RETURN (RR); 

END; 

END.CASE: 

CASE  TYPEOFCB)  OF 
INTEGER  : BEGIN; 

RR 

A+B; 

RETURN (RR) ; 

END; 

REAL 

: BEGIN: 

RR 

:■  A+B; 

RETURN(RR) ; 

END; 

END.CASE; 


END. CASE; 
END.FUNCTION; 


Operations  on  Number  Types: 


+ - 

I form  I op  1 description  I 

t- 

I unary  I I no  effect  I 

I unary  I - I negates  the  operand  I 

i binary  I I foras  the  sun  of  the  operands  I 

I binary  1 - I forms  the  difference  of  the  operands  I 

1 binary  I • I forms  the  product  of  the  operands  I 
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1 binary 

1 

/ 1 

loras  real  quotient 

1 

1 binary 

1 

div  1 

converts  operands  to  integer  and  Ions 

integer 

1 

1 

1 

1 

quotient 

1 

1 binary 

1 

■od  1 

converts  operands  to  integer  and  loras 

integer 

1 

1 

1 

1 

Bodulus 

1 

1 binary 

1 

**  1 

raises  opl  to  the  power  op2 

I 

1 binary 

1 

m 1 

coapares  lor  equality 

1 

1 binary 

1 

<>  1 

compare s lor  inequality 

1 

1 binary 

1 

< 1 

coapares  lor  less  than 

1 

1 binary 

1 

<■  1 

coapares  lor  less  than  or  equal 

1 

1 binary 

1 

> 1 

compares  lor  greater  than 

1 

1 binary 

4......... 

1 

>■  1 

compares  lor  greater  than  or  equal 

1 

A. 8.6  Enumeration  Type 
Description 

Afi  Enumeration  is  an  ordered  set  of  values  represented  by  names.  Note  that  the  enumeration 
type  can  only  be  used  as  a defined  type. 

Each  enumeration  item  exists  at  the  same  scope  as  the  type  of  the  enumeration  itself.  Thus, 
given  the  example  below,  the  identifiers  colors,  red,  blue,  and  green  all  exist  at  the  same  lexical 
scope. 

Syntax 


201  ENUMERATION-TTPE  - ENUMDUTION  OF  NESTED -ID -LIST  . 


Rules  and  Restrictions: 


1.  Each  identifier  declared  as  an  enumerated  item  becomes  a unique  identifier  in  the  current 
scope. 

2.  Each  enumerated  item  has  a value  that  is  dependent  on  its  position  in  the  list.  The  value 
of  the  first  item  is  less  than  the  second;  the  second  is  leas  than  the  third,  etc.  The  specific 
value  is  not  relevant. 

Example: 


This  example  shows  an  enumeration  of  colors. 

COLORS  - ENUMERATION  OF  (RED.  BLUE.  GREEN); 
(•  RED  < BLUE.  BLUE  < GREEN  *) 
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OperatioDB  on  Enumeration  Types 


form  i 

op  1 

description 

binary  I 

• 1 

coopares  for  equality 

binary  1 

<>  1 

eoapares  lor  inequality 

binary  I 

< 1 

coapares  for  less  than 

binary  1 

<■  1 

compares  for  less  than  or 

equal 

binary  1 

> 1 

compares  for  greater  than 

binary  1 

>■  1 

coapares  for  greater  than 

or  equal 

A. 8. 7 Select 
Type 

Description 

A Select  type  is  used  when  a choice  must  be  made  among  a number  of  possible  entity  types. 
Syntax 


245  SELECT-TYPE  • SELECT  NESTED- ID -LIST  . 
Rules  and  Restrictions 


1.  Each  identifier  in  the  selection  list  must  be  an  entity  identifier  or  a select  type. 
Example 

A choice  must  be  made  among  several  dissimilar  things  in  a given  context. 

TYPE 

irbitraryChoice  • SELECTCNAIL,  SCREW,  GLUE); 

END.TYPE 

AttachaentMethod  : irbitraryChoice; 

An  AttachmentMethod  can  be  any  of  the  entities  named  NAIL,  SCREW,  or  GLUE. 
Operations  on  Select  Types 

No  operations  are  defined  for  the  select  type. 


A. 8. 8 Generic  Type 
Description 
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A Generic  type  is  used  to  represent  sny  type.  The  purpose  of  the  generic  type  is  to  en&ble 
the  writing  of  generic  functions  and  procedures. 

Syntax 

213  GENERIC-TTPE  • GENERIC  }\\ 

Rules  and  Restrictions 

1.  A generic  type  can  only  be  used  as  a parameter  type  in  a function  or  procedure  formal 
parameter  list  or  as  the  result  type  of  a function. 

Example: 

This  example  shows  a generic  function  that  adds  numbers  or  vectors.  It  is  an  elaboration  of 
the  example  given  above  in  7.1.1. 


FUNCTION  ADD (A . B ; GENERIC) : GENERIC ; 

— INTEGER  RESULT 
--  REAL  RESULT 
— VECTOR  RESULT 

END.LOCAL: 

CASE  TYPEOF(A)  OF 


LOCAL 

RI  : 

INTEGER; 

RR  : 

REAL; 

RV  : 

VECTOR; 

INTEGER  : CASE  TYPEOF(B)  OF 

INTEGER  : BEGIN;  RI 
REAL  : BEGIN; 

END. CASE; 

REAL  : CASE  TYPEOF(B)  OF 
INTEGER  : BEGIN; 

REAL  : BEGIN; 

END. CASE; 

VECTOR  : IF  TTPEOF(B) -VECTOR  THEN 


RR 


RR 

RR 


A+B;  RETURN (RI);  END; 
A+B;  RETURN (RR);  END; 


A^B;  RETURN(RR);  END; 
A+B;  RETURN(RR);  END; 


RV.I 
RV.J 
RV.K 
RETURN (RV) ; 
END.IF; 


A.I+B.I 

A.J+B.J 

A.K^B.K 


END.CASE; 
END .FUNCTION; 


Operations  on  Generic  Types: 

No  operations  are  defined  for  generic  types.  You  must  first  determine  the  actual  type  (by  the 
TypeOf  built-in  function)  and  then  use  the  appropriate  operation  set  for  that  type. 
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A.O  Built-in  Constants 

The  built-in  constants  are  assumed  to  have  exact  values,  even  though  an  exact  value  may  not 
exist  in  the  real  world;  e.g.,  pi  is  assumed  to  be  exact. 

A.0.1  Infinity 

The  infinity  symbol  (#}  stands  for  an  indeterminate  upper  bound  of  a LIST  or  SET. 

A.9.2  False 

False  is  the  opposite  of  True;  see  below. 

A.9.3  Pi 

Pi  is  the  number  3.14159....  It  is  assumed  that  this  number  is  exact. 

A. 9. 4 True 

True  False  and  Unknown  together  make  up  a ternary  logic  system  in  which  False  is  NOT 
True  and  Unknown  is  neither  True  nor  False. 

A.9.5  Unknown 

Unknown  is  a logic  state  which  indicates  that  the  value  is  neither  TVue  nor  False. 

A.9.6  Built-in  Functions 

All  functions  (and  mathematical  operations  in  general]  are  assumed  to  yield  exact  results. 
Functions  that  operate  on  angles  express  angular  measurement  in  terms  of  radians. 

A. 9. 7 Abs  - Arithmetic  Function 

FUNCTION  ABS  ( V: NUMBER  ) : NUMBER; 

The  Abs  function  finds  the  absolute  value  of  V and  returns  the  result  (integer  or  read  depending 
on  the  type  of  the  input)  to  the  point  of  invocation. 

Example: 


ABS  ( -10  ) -->  10 

A.9.8  ACos  - Arithmetic  Function 

FUNCTION  ACOS  ( V: NUMBER  ) : REAL; 

The  ACos  function  finds  the  arc-cosine  of  V and  returns  a real  in  radians  to  the  point  of 
invocation. 

Example: 
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ACOS  ( 0.3  ) -->  1.266103. . . 

A.0.0  ASin  • Arithmetic  Function 

FUNCTION  ASIN  ( ViNUMBER  ) : REAL; 

The  ASin  function  finds  the  arc^sine  of  V and  returns  a real  result  in  radians  to  the  point  of 
invocation. 

Example: 


ASIN  ( 0.3  ) -->  3.04692. . .e-1 

A. 0.10  ATan  • Arithmetic  Function 

FUNCTION  ATAN  ( VlrNUMBER  [ ; V2:NUMBER  ] ) : REAL; 

The  ATan  function  finds  the  arctangent  of  V and  returns  a real  result  in  radians  to  the  point 
of  invocation. 

* 

ATAN  ( vl  [.  v2]  ) 

The  argument  vl  must  always  be  specified;  the  argument  v2  is  optional.  If  vf  is  omitted, 
vl  represents  the  value  whose  arctangent  is  to  be  found.  If  vf  is  specified,  the  value  whose 
arctangent  is  to  be  found  is  taken  to  be  the  expression  vl/vi  and  in  the  case  where  v2  is  zero 
the  result  is  pi/2  or  •pi/2  depending  on  the  sign  of  vl. 

Example: 


ATAN  ( 0 ) -->  0.0 

ATAN  ( X.  y ) 

ATAN  ( -6.5,  3.0  ) -->  -1.071449... 

A.9.11  Cos  - Arithmetic  Function 
FUNCTION  COS  ( V: NUMBER  ) : REAL; 

The  Cos  function  finds  the  cosine  of  V expressed  in  radians  and  returns  a real  result  to  the 
point  of  invocation. 

Example: 


COS  ( 0.5  ) -->  8.77582. . .E-1 

A.0.12  Exists  - General  Function 

FUNCTION  EXISTS  ( V ) : LOGICAL: 

The  Exists  function  accepts  any  variable  and  returns  True  if  a value  exists  for  that  parameter, 
or  False  when  no  value  exists  for  it.  Note  that  only  attributes  declared  with  the  Optional 
keyword  can  ever  have  a missing  value. 

Example: 
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if  EXISTS  ( a ) then 


A.0.13  Exp  • Arithmetic  Function 

FUNCTION  EXP  ( V:NUMBER  ) : REAL; 

The  Exp  function  raises  e (the  base  of  the  natural  logarithm  system)  to  the  power  V and 
returns  a real  to  the  point  of  invocation. 

Example: 

EXP  ( 10  ) -->  2.202646. . .E+4 

A.9.14  HlBound  - Arithmetic  Function 

FUNCTION  HIBOUND  ( V ) : INTEGER; 

The  HiBound  function  returns  the  actual  upper  bound  of  an  Array,  List,  or  Set.  The  result 
depends  on  the  type  of  the  actual  parameter  V.  If  the  actual  parameter  is: 


Actual  Parameter  Type 

Result 

Array 

the  declared  upper  bound  of  the  array 

List 

the  number  of  elements  actually  in  the  list. 

Set 

the  number  of  elements  actually  in  the  set. 

any  non-aggregate 

1 (one). 

Example: 


LOCAL 

A : ARRAY [-3: 10]  OF  SET  OF  LIST[0:#]  OF  INTEGER: 

HI.  H2.  H3  : INTEGER; 

END .LOCAL; 

AC-3]Cl][l]  2; 

HI  :■  HIBOUND(A);  --  -lO  (UPPER  BOUND  OF  ARRAY) 

H2  HIB0UND(A[-3]) ; --  -1  (SIZE  OF  SET) 

H3  :•  HIBOUND (A [-3] [1]) ; --  -1  (SIZE  OF  LIST) 

A.0.15  LoBound  - Arithmetic  Function 

FUNCTION  LOBOUND  ( V ) : INTEGER; 


The  LoBound  function  returns  the  actual  lower  bound  of  an  Array,  List,  or  Set.  The  result 
depends  on  the  type  of  the  actual  parameter  V.  If  the  actual  parameter  is: 


Ul 


Actual  Parameter  Type 

Result 

Array 

the  declared  lower  bound  of  the  array 

List 

0 (zero)  if  the  list  is  empty;  otherwise  1 (one). 

Set 

0 (zero)  if  the  set  is  empty;  otherwise  1 (one). 

any  non>aggregate 

1 (one). 

Example; 


LOCAL 

A : ARRAY [-3: 10]  OF  SET  OF  LISTCO:#]  OF  INTEGER; 

El.  H2.  E3  : INTEGER; 

END.LOCAL; 

HI  LOBOUNOCA);  — —3  (LOWER  BOUND  OF  ARRAY) 

H2  LOBOUND(A[-3]):  — -0  (SIZE  OF  SET) 

H3  L0B0UND(A[-3] [1]);  — -0  (SIZE  OF  LIST) 

A.9.16  Log  • Arithmetic  Function 

FUNCTION  LOG  ( V; NUMBER  ) : REAL; 


The  Log  function  finds  the  natural  logarithm  of  V and  returns  a real  result  to  the  point  of 
invocation. 

Example: 


LOG  ( 4.5  ) -->  1.504077. . .EO 

A.9.17  Log2  - Arithmetic  Function 

FUNCTION  L0G2  ( V; NUMBER  ) : REAL; 

The  Log2  function  finds  the  base  2 logarithm  of  V and  returns  a real  result  to  the  point  of 
invocation. 

Example: 


Log2  ( 8 ) -->3 

A.9.18  LoglO  - Arithmetic  Function 

FUNCTION  LOGIC  ( V: NUMBER  ) : REAL; 

The  LoglO  function  finds  the  base  ten  logarithm  of  V and  returns  a real  to  the  point  of 
invocation. 

Example: 


LOGIO  ( 10  ) -->  1.00. . .EO 
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A. 0.19  Odd  - Arithmetic  Function 

FTOCTION  ODD  ( V; INTEGER  ) : LOGICAL; 

The  Odd  function  accepts  any  integer  value  V and  returns  True  if  the  number  is  odd;  i.e.,  -3, 

-1,  1,  3,  5 ... 

Example; 


ODD  ( 121  ) — > TRUE 

A.9.20  Sin  - Arithmetic  Function 

FUNCTION  SIN  ( V: HUMBER  ) : REAL; 

The  Sin  function  finds  the  sine  of  V expressed  m radians  and  returns  a real  result  to  the  point 
of  invocation. 

Example: 

SIN  ( pi  ) -->  0.0 

A.9.21  SizeOf  - Aggregate  Function 

FUNCTION  SIZEOF  ( V: AGGREGATE  ) : INTEGER; 

The  SkeOf  function  accepts  any  aggregate  type  and  returns  the  number  of  elements  in  it. 

The  returned  value  for  an  Array  will  be  its  declared  number  of  elements. 

The  returned  value  for  a List  will  be  the  number  of  occupied  elements. 

The  returned  value  for  a Set  will  be  the  number  of  actual  elements. 

Example: 

LOCAL 

N : NUMBER; 

X : LISTCl:#]  OF  Y; 

N - SIZEOF  ( I ) ; 

A.9.22  Sqrt  - Arithmetic  Function 

FUNCTION  SORT  ( V; NUMBER  )’:  REAL; 

The  Sqrt  function  finds  the  square  root  of  the  non-negative  numeric  value  V and  returns  a real 
result  to  the  point  of  invocation. 

Example: 


SQRT  ( 121  ) -->  11 


A.9.33  Tan  - Arithmetic  Function 


FUNCTION  TAN  ( V:NUMBEE  ) : REAL; 

The  Tan  fxmction  finds  the  tangent  of  V and  returns  a real  to  the  point  of  invocation. 
Example: 


TAN  ( 0.0  ) -->  0.0 

A.9.24  TypeOf  - General  Function 

FUNCTION  TTPEOF  ( V ) : SET  OF  TTPE; 

The  TypeOf  function  accepts  any  variable  V and  returns  a set  containing  its  type.  When  V is 
an  entity  subtype  the  set  contains  the  type  of  the  entity  itself  and  each  of  its  supertype  entity 
types,  etc.  until  there  are  no  more  supertype  entity  types. 

Example: 


il  TTPEOF  ( a ) -point  THEN 


A.9.25  Value  • Arithmetic  Function 

FUNCTION  VALUE  ( V: STRING  ) : NUMBER; 

The  Value  function  converts  a string  variable  or  string  literal  to  its  numeric  equivalent  and 
returns  the  result  to  the  point  of  invocation.  The  type  of  the  result  matches  the  type  of  the 
input  string.  If  the  string  cannot  be  converted  to  a number,  the  returned  value  is  zero. 
Example: 


VALUE  ( •1.234‘  ) -->  1.234  (REAL) 

VALUE  ( '20*  ) -->20  (INTEGER) 

A. 10  Built-in  Procedures 

A. 10.1  Insert  - List  Procedure 

PROCEDURE  INSERT  ( VAR  LrLIST;  E;  P; NUMBER  ) ; 

The  Insert  procedure  is  used  to  insert  an  element  compatible  with  a list  variable  into  that  list 
variable.  X is  a list,  F is  an  element  compatible  with  the  type  of  L and  P is  a number  indicating 
where  E is  inserted  into  the  list.  The  value  of  P must  satisfy: 

{ 0 <-  P <-  Si2e0i(L)  } 

E is  inserted  after  the  list  element  indicated  by  P.  For  example,  when  P=0  E becomes  the  first 
element  in  the  list. 


A. 10. 2 Nullify  - General  Procedure 

PROCEDURE  KUU.IFT  ( VAR  V ) ; 


The  Nullify  procedure  accepts  a variable  of  any  type  and  nullifies  its  value.  Nullification  meams 
causing  a value  associated  with  an  attribute  to  cease  to  exist.  That  is,  the  attribute  no  longer 
has  a value  after  nullification.  Attempts  to  nullify  an  attribute  not  declared  as  optional  has  no 
effect  on  its  value. 

A. 10. 3 Violation  - General  Procedure 

PROCEDURE  VIOLATION  ; 

The  Violation  procedure  raises  an  exception.  This  procedure  can  be  invoked  inside  a rule 
to  indicate  that  some  global  constraint  has  been  violated.  Other  than  having  the  ability  to 
indicate  that  an  exceptional  condition  exists,  Expreaa  provides  no  mechanism  for  recovering 
from  it. 
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A. 11  Statements  and  Blocks 

A slfttement  is  s sequence  of  tokens  th&t  conform  to  the  grammar  of  Express.  Most  state- 
ments are  terminated  by  the  semicolon  character.  There  are  a few  exceptions  to  this  rule.  For 
example,  the  TYPE  statement  which  starts  a type  definition  block  is  not  terminated  with  a 
semicolon. 

Certain  sequences  of  statements  are  called  blocks.  All  of  the  statements  that  make  up  a block 
are  treated  logically  as  a single  statement.  There  are  two  kinds  of  blocks:  declaration  blocks 
and  execution  blocks.  The  declaration  blocks  are  the  Schema  Entity  Map  Type  and  Local 
blocks.  Functions  procedures,  and  niles  are  called  execution  blocks. 

The  outermost  block  must  be  a Schema  block.  A schema  contains  all  declarations  including 
possibly  other  schemas. 

Some  blocks  establish  a scope  over  which  identifiers  must  be  unique.  Every  identifier  declara- 
tion within  those  blocks  must  be  unique.  The  type  block  u a pseudo-block;  it  does  not  spawn 
a new  identifier  scope.  For  example,  the  names  of  the  attributes  of  an  entity  are  unique  to  the 
entity  block  in  which  they  are  declared.  The  same  attribute  identifier  could  be  used  in  another 
entity  since  each  entity  establishes  its  own  scope. 

Examples 


SCHEMA  exanple;  ♦ 

I 

ENTITY  entityl;  ♦ I this  is  a block 

a : integer:  I this  is  a block  I 

b : integer;  I inside  a block  I 

END .ENTITY:  ♦ I 

I 

ENTITY  entity2;  ♦ I 

a : entityl:  I this  is  a block  I 

b : Integer;  I inside  a block  I 

END .ENTITY;  ♦ I 

I 

END.SCHEMA:  ♦ 


A. 11.1  Schema 
Description 

A Schema  contains  all  of  the  declarations  needed  to  describe  some  problem  area.  A schema 
can  declare  types,  rules,  entities,  functions,  procedures,  and  even  other  schemas.  It  can  also 
contain  directives  and  remarks  as  needed. 

In  general,  a declaration  does  not  have  to  precede  references  to  it.  Position  is  important  for 
two  directives.  A Define  directive  must  appear  before  a reference  to  the  replacement  symbol 
it  declares.  Likewise,  an  Assume  directive  must  be  given  prior  to  any  references  that  would 
be  resolved  in  one  of  the  assumed  schemas. 
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Syntax 


244  SCHEMA-DECL  - SCHEMA  SCHEMA- ID  SEMICOLON  { BLOCK-MEMBER  } 

END-SCHEMA  SD<ICOLON  . 

187  BLOCK-MEMBER  ■ ENTITT-DECL  I MAP-DECL  | FDNCTION-DECL  I PROCEDDRE-DECL 
I RULE-DECL  I SCHEMA-DECL  I TTPE-DECL  I DIRECTIVE  . 

107  DIRECTIVE  • ASSUME-DIRECTIVE  I DEFINE-DIRECTIVE  I EXPORT-DIRECTIVE 
I INCLDDE-DIRECTIVE  I USES -DIRECTIVE  . 

184  ASSUME-DIRECTIVE  ■ ASSUME  LEFT-PAREN  SCHEMA-ID  { COMMA  SCHEMA-ID  } 
RIGHT-PAREN  SEMICOLON  . 

103  DEFINE-DIRECTIVE  - DEFINE  DEFINED -TYPE -ID  STRING-LITERAL  SEMICOLON  . 
206  EXPORT-DIRECTIVE  ■ EXPORT  ( NESTED-ID-LIST  I EVERYTHING 
I EVKYTHING  EXCEPT  NESTED -ID -LIST  ) SEMICOLON  . 

21«  INCLUDE-DIRECTIVE  - INCLUDE  STRING -LITERAL  SEMICOLON  . 

265  USES -DIRECTIVE  - USES  NESTED -ID -LIST  SEMICOLON  . 


A. 11. 2 Type  Declarations 
Description 

Any  user  defined  types  must  be  declared  In  a Type  block.  Each  defined  type  is  a unique  type 
that  is  not  assignment  compatible  with  other  built-in  or  user  defined  types.  This  is  true  eveu 
if  the  underlying  types  are  the  same. 

Syntax 


261  TTPE-DECL  • TYPE  TYPE-ITEM  { TYPE-ITEM  } END-TYPE  SEMICOLON  . 


Examples 


TYPE 

MASS  - REAL  ; 

VOLUME  - REAL  : 

END.TYPE  : 

Whenever  MASS  or  VOLUME  is  used  as  a data  type,  a REAL  is  used  to  store  the  value  of  a 
variable.  MASS  and  VOLUME  are  incompatible  types  however.  That  is,  it  is  illegal  to  assign 
a variable  of  type  MASS  to  a variable  of  type  VOLUME. 


A. 11. 3 Entity 

Description 

A Entity  declaration  creates  an  entity  type.  The  entity  type  represents  some  thing,  concept, 
event,  etc.  that  is  important  to  a schema.  An  entity  instance  is  an  occurrence  of  an  entity  type 
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as  in  a database.  The  word  entity  used  alone  means  entity  type.  Whenever  an  entity  occurrence 
is  intended  the  words  entity  instance  will  be  used. 

An  entity  is  defined  in  terms  of  a set  of  attributes.  Explicit  attributes  represent  the  data  one 
would  expect  to  find  in  a database.  Derived  attributes  represent  information  that  can  be  com- 
puted as  needed  from  other  attributes.  Derived  attributes  are  declared  following  the  Derive 
keyword. 

Uniqueness  constraints  are  specified  following  the  Unique  keyword.  Uniqueness  can  be  specified 
for  individual  attributes  or  combinations  of  attributes. 

It  is  often  necessary  to  define  a number  of  constraints  that  apply  to  the  explicit  attributes, 
either  individually  or  in  combination  with  one  another.  These  constraints  are  defined  following 
the  Where  keyword. 

The  combination  of  explicit  attributes,  derived  attributes,  and  constraints  is  often  sufficient  to 
fully  define  the  intended  characteristics  of  an  entity.  On  occasion  however,  a more  complex 
constraint  is  needed  to  fully  define  the  behavior  of  an  entity.  See  the  section  titled  Rule  for 
more  information  on  this  subject. 

Syntax 


IW  ENTITY-DECL  - ENTITT  ENTITY- ID  [ SUBSUPER-DECL  ] SEMICOLON 
[ EXPLICIT-ATTRIBUTE-DECL  ] [ DERIVED-ATTRIBUTE-DECL  ] 

[ UNiqUE-RULE  ] [ WHERE-RULE  ] END-ENTITY  SEMICOLON  . 

204  EIPLICIT-ATTRIBUTE-DECL  • EXPLICIT-ATTRIBUTE  { EXPLICIT-ATTRIBUTE  } . 

203  EXPLICIT- ATTRIBUTE  • ID-LIST  COLON  [ OPTIONAL  ] [ EXTERNAL  I INTERNAL 
I DYNAMIC  ] ATTRIBUTE-CAN-BE  SEMICOLON  . 

106  DERIVED-ATTRIBUTE-DECL  - DERIVE  DERIVED -ATTRIBUTE  { DERIVED-ATTRIBUTE  } . 
105  DERIVED -ATTRIBUTE  - ATTRIBUTE-ID  COLON  RESULT-CAN-BE  INITIALIZER 
SEMICOLON  . 

219  INITIALIZER  - ASSIGNMENT- OPERATOR  EXPRESSION  . 

263  UNIQUE-RULE  - UNIQUE  { ID-LIST  SEMICOLON  } . 

266  WHERE-RULE  - WHERE  { EXPRESSION  SEMICOLON  } . 


A. 11. 3.1  Supertypes  and  Subtypes 
Description 

An  Entity  Sub  Type  is  a kind  or  variety  of  the  entity  that  b its  supertype.  All  of  the  subtype 
entities  that  share  the  same  supertype  have  certain  characteristics  in  common.  These  common 
characteristics  may  be  material;  i.e.,  the  attributes  of  the  supertype  entity  are  implicitly  part 
of  each  subtype  entity.  In  some  cases  entities  that  share  a common  sup>ertype  may  share  no 
attributes,  but  are  still  constructed  as  subtypes  because  they  are  widely  understood  to  be 
related  entities. 
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Syntax 

2S4  SUBSUPS-DECL  • SUBTYPE-DECL  [ SUPSTYPE-DECL  ] I SUPERTTPE-DECL 
I SUBTTPE-DEa  ] . 

An  Entity  SuperType  must  mention  those  entities  that  are  its  subtype.  Likewise,  an  entity 
that  is  a subtype  must  mention  eaoh  of  its  supertyp^.  The  relationship  between  a supertype 
entity  and  its  subtype  can  be  inclusion  (ond)  or  exclusion  (er  or  zer)  . If  a subtype  entity 
has  more  than  one  supertype  entity,  the  relationship  is  always  mclusion  (this  means  that  the 
existence  of  a subtype  depends  on  the  existence  of  all  of  its  supertypes). 

Examples 

Assume  entities  named  A,  B,  C,  D,  E,  and  F.  Entiti^  B,  C,  and  D are  subtypw  of  entity  A. 
Entitle  D and  F are  subtypes  of  entity  E.  If  we  assume  exclusion  in  all  czam,  the  entity  headers 
for  each  entity  would  look  like: 


ENTITY 

i 

SUPSTYPE 

OF 

(B  xor 

C xor  D) 

ENTITY 

B 

SUBTYPE 

OF 

(A); 

ENTITY 

C 

SUBTYPE 

OF 

(A): 

ENTITY 

D 

SUBTYPE 

OF 

(A.  E): 

ENTITY 

E 

SUPERTYPE 

OF 

(D  xor 

F); 

ENTITY 

F 

SUBTYPE 

OF 

(E); 

k E 

/ I \ / \ 

/ I \ / \ 

BCD  F 

The  dependency  relationships  that  can  exist  for  this  configuration  are: 


Given  an  instance  of: 

There  must  also  exist: 

A 

B xor  C xor  D 

B 

A 

C 

A 

D 

A and  E 

E 

D xor  F 

F 

E 

An  instance  of  a subtype  entity  demands  the  existence  of  each  of  i^  supertypes. 

If  a supertype  entity  has  an  attribute,  that  attribute  is  implicitly  known  to  each  of  its  subtypes. 
Thus,  if  the  entity  A above  had  an  attribute  c^led  a,  the  entities  B,  C,  and  D also  have  the 
very  same  a attribute.  This  means  that  entity  E cannot  also  have  an  attribute  called  a since 
entity  Z?  would  have  no  way  of  distinguishing  between  the  two  attributes. 

The  form  of  the  supertype  declaration  can  specify  both  inclusion  and  exclusion.  For  example, 
the  entity  header: 
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ENTITT  X SUPERTYPE  OF  ((P  xor  Q)  and  R) ; 


lays  that  entity  X is  at  the  same  time  a supertype  of  either  entities  P and  R,  or  Q and  R. 

You  can  also  indicate  that  a supertype  entity  might  have  no  subtype  as  in: 

ENTITT  I SUPERTYPE  OF  (A  xor  B xor  HULL) ; 

Meaning  that  entity  X is  a supertype  of  A or  R or  nothing  at  all.  Note  that  the  and  operator 
cannot  be  used  with  NULL. 

A.11.3.2  Attribute 

An  entity  is  defined  in  terms  of  a set  of  attributes,  which  are  the  entity’s  essential  traits, 
qualities,  or  properties.  Attributes  can  be  explicit  data  or  the  value  can  be  derived. 

A. 11. 3. 2.1  Explicit  Attribute 


Description  i 

An  explicit  attribute  represents  actual  data  that  one  might  expect  to  find  in  a database  imple- 
mentation. 

Syntax 


204  EIPLICIT-ATTRIBUTE-DECL  - EXPLICIT-ATTRIBUTE  { EXPLICIT-ATTRIBUTE  } . 
203  EXPLICIT-ATTRIBUTE  • ID-LIST  COLON  [ OPTIONAL  ] [ EXTERNAL 
I INTERNAL  I DYNAMIC  ] ATTRIBUTE-CAN-BE  SEMICOLON  . 


Several  attributes  that  are  alike  in  all  respects  can  be  declared  together  as  in: 


ENTITY  point  ; 

X,  y,  2 : real  ; 
END.ENTITY  ; 


which  is  equivalent  to: 


ENTITY  point  : 
X : real  ; 
y : real  ; 
z : real  ; 
END.ENTITY  ; 
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Optional  indicates  that  an  attribute  does  not  have  to  have  a value. 

An  explicit  attribute  can  be  both  Optional  and  Unique  at  the  same  time  (see  ‘Uniqueness 
Rule”  below).  When  an  attribute  is  declared  as  both  Optional  and  Unique  and  the  value 
in  an  instance  is  missing,  that  value  is  exempt  from  the  uniqueness  test.  If  neither  of  these 
keywords  are  given,  the  attribute  value  u mandatory  (not  optional)  and  not  unique. 

External  Internal  and  Dynamic  can  be  used  alone  or  in  combination  with  the  Optional  or 
Unique  keywords.  These  keywords  specify  the  kind  of  ownership  the  entity  has  over  attribute 
values.  If  none  of  these  keywords  are  used.  Dynamic  is  assixmed. 

External  says  that  the  attribute  value  exists  outside  the  scope  of  the  entity,  and  potentially 
can  be  shared  by  several  entities. 

Internal  says  that  the  attribute  value  exists  within  the  scope  of  the  entity,  and  cannot  be 
shared  by  any  other  entity. 

Dynamic  says  that  the  attribute  can  exist  within  an  entity  instance  sometimes  and  outside  it 
at  other  times. 


A. 11. 3. 2. 2 Derived  Attribute 
Description 

A derived  attribute  represents  information  that  is  computed  m some  manner.  Derived  attributes 
must  be  declared  following  the  Derive  keyword.  Each  derived  attribute  must  be  specihed  in- 
dividually. The  type  of  the  attribute  follows  the  colon  as  in  an  explicit  attribute  declaration; 
then  the  derivation  is  given  as  an  expression.  Ail  of  the  parameters  used  in  the  expression  must 
be  literals  or  explicit  or  derived  attributes  of  the  entity  being  declared. 

Syntaix 


106  DERIVED-ATTRIBUTE-DECL  - DERIVE  DERIVED -ATTRIBUTE  < DERIVED -ATTRIBUTE  } . 
105  DERIVED-ATTRIBUTE  - ATTRIBUTE-ID  COLON  RESULT-CiN-BE  INITIALIZER 
SEMICOLON  . 

210  INITIALIZER  - ASSIGNMENT-OPERATOR  EXPRESSION  . 

Examples 

In  the  following  example  a circle  is  defined  by  three  points  through  which  it  passes.  These  three 
points  represent  the  data  by  which  the  circle  is  defined.  In  addition  to  these  data  there  is  a 
need  to  account  for  important  traits  such  as  the  radius,  or  the  axis.  This  is  accomplished  by 
defining  them  as  derived  attributes,  giving  the  value  as  an  expression. 

FUNCTION  iKpl  ,p2.p3:point)  ;real  ; 

(*  Compute  RADIUS  of  circle  given  three  points  on  circumference  •) 
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END .FUNCTION 

FUNCTION  12(pl  .p2.p3:poiiit)  rvtctor  ; 

(*  Coopnte  AXIS  oi  circle  given  three  points  on  clrcnnlerence  *) 
END_FUNCTION  ; 

ENTITT  circle  ; 

pi.  p2,  p3  : point  ; 

DERIVE 

rsdins  : real  :■  Il(pl.p2,p3)  ; 

axis  ; vector  :■  12(pl.p2.p3)  ; 

area  : real  :■  pi*radlns«*2  : 

END.ENTITT  ; 

The  three  defining  points  (PI,  P2,  and  P3)  are  explicit  attributes.  Radius,  Axis,  and  Area  are 
derived  information.  The  values  of  these  derived  attributes  are  computed  by  the  expression 
following  the  assignment  operator.  The  values  of  Radius  and  Axis  are  obtained  by  means  of  a 
function  call;  the  value  of  Area  is  computed  in>line.  Note  that  the  type  given  after  the  colon 
must  be  assignment  compatible  with  the  result  produced  by  the  expression. 

A. 11. 3. 3 Uniqueness  Rule 


Description 

A uniqueness  constraint  can  be  given  for  individual  explicit  attributes  or  combinations  of  them 
by  means  of  a Unique  rule.  The  uniqueness  rules  follow  the  Unique  keyword.  Each  rule  lists 
the  attribute  names  whose  values  must  be  unique.  When  such  a list  has  two  or  more  attribute 
names,  the  values  are  jointly  unique. 

If  an  entity  had  three  attributes  called  A,  B,  and  C,  we  could  have: 

UNIQUE 

A: 

B: 

C; 

which  means  that  the  uniqueness  constraint  applies  to  each  of  the  attributes  individually.  Or 
we  could  have: 

UNIQUE 

A.B; 

B; 

C; 

This  means  that  the  uniqueness  constraint  applies  jointly  to  A and  B together,  and  also  to  B 
and  C individually. 

Examples 
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A person^ame  entity  might  look  Uke: 


ENTITY  PffiSON.NAME; 
UST  : SmiNG 

FIRST  : STRING 

MIDDU:  : STRING 

MICKNAME  : STRING 

EJD .ENTITY; 

and  it  might  be  used  as: 


DJTITY  EMPLOYEE: 

BADGE  : NDMEER; 

NAME  : PERSON.NAME; 

UNIQUE' 

BADGE,  NAME; 

END.ENTITY; 


and  as: 


ENTITY  ROSTER; 

NAME  : LIST  CO:#]  OF  PERSON.NAME; 

END.ENTITY; 

The  uniquen^  constraint  is  not  stated  within  the  person^ame  entity  since  it  is  not  clear  that 
names  always  have  to  be  different.  The  roster  entity  do«  not  insist  that  names  are  different.  In 
the  case  of  an  employee,  however,  there  is  a requirement  for  unique  identification.  The  example 
shows  that  BADGE  and  NAME  together  have  to  be  unique.  This  allows  the  value  of  BADGE 
in  one  employee  entity  instance  to  be  the  same  as  another  instance;  likewise  for  the  value  of 
NAME.  The  two  values  taken  together  have  to  be  unique  however. 

Uniqueness  spans  some  collection  of  entity  instances.  That  collection  could  reasonably  be  called 
a database.  So,  within  a given  database,  the  attribute,  or  set  of  attribute,  or  combination  of 
attributes  must  be  distinctly  different  throughout. 


A. 11. 3. 4 Local  Rule 


Description 

Local  rules  are  used  to  specify  conditions  that  constrain  the  value  of  individual  attributes  or  a 
combinations  of  attributes.  All  local  rules  must  follow  the  Where  keyword. 


Syntax 
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256  WHERE-RULE  - WHERE  { EXPRESSION  SDdCOLON  > . 

Each  expression  m\ist  yield  a logical  (True  or  False)  result.  The  variables  used  in  the  expres- 
sions must  be  the  names  of  attributes  that  are  declared  for  this  entity. 

For  example,  a unit.vector  requires  that  the  length  of  the  vector  be  exactly  one.  This  constraint 
can  be  specified  by: 


DTTITT  unit.vector  ; 

a.  b.  e : real  ; 

WHERE 

a**2  ♦ b**2  ♦ e**2  ■ 1.0  ; 

END.ENTin  : 

Local  rules  deal  with  optional  attributes  sometimes.  That  part  of  a rule  which  contains  an 
optional  attribute  is  treated  as  if  it  did  not  exist  when  the  value  of  that  attribute  does  not 
exist.  Modifying  the  previous  example: 


ENTITY  unit.vector  ; 
a,  b : real: 
c : optional  real  ; 

WHERE 

a»»2  ♦ b**2  ♦ c**2  ■ 1.0  ; 

ENO.ENTITY  ; 

When  e has  a value  the  rule  expression  is  evaluated  normally,  but  when  e has  no  value  the 
subexpression  ■+■  e**2  has  no  evaluation. 


A. 11. 4 Map  Declaration 

Description 

A Map  is  a declaration  that  modifies  an  entity  for  some  purpose.  The  effect  of  declaring  a 
Map  is  to  declare  an  entity.  Mapping  can  give  a different  name  to  an  entity,  alter  the  type 
of  an  attribute  (if  the  new  type  is  compatible  with  the  old  type),  introduce  new  subtypes  and 
supertypes,  and  add  local  rules. 

Syntax 


228  MAP-DECL  • MAP  MAP-ID  FROM  ENTITY-ID  [ SUBSUPER-DECL  ] 
SEMICOLON  { RETYPE-DECL  } [ UNIQUE-RULE  ] 

[ WHERE-RULE  ] END-MAP  SEMICOLON  . 

263  UNIQUE-RULE  • UNIQUE  < ID-LIST  SEMICOLON  } . 

266  WHERE-RULE  - WHERE  { EXPRESSION  SEMICOLON  > . 
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Examples 

A vertex  entity  is  defined  as: 

ENTITT  VERTEX; 

PT  : OPTIONAL  POINT; 

END .ENTITT; 

A specific  application  of  the  vertex  entity  (i.e.,  another  schema)  requires  that  the  point  compo- 
nent of  vertex  is  mandatory.  This  is  accomplished  by; 

MAP  VERTEX  FROM  VERTEX; 

WHERE 

(EXISTS (PT)); 

END .MAP; 

This  example  assumes  that  there  b an  entity  named  vertex  vbible  in  the  scope  of  the  mapped 
entity  (also  called  vertex)  . The  attributes  of  the  mapped  vertex  do  not  have  to  be  written  as 
they  (it  in  thb  case)  are  automatically  part  of  the  mapped  entity.  The  local  rule  states  that 
the  attribute  named  pt  must  not  be  null,  thus  making  it  mandatory. 

Another  application  wbhes  to  call  an  entity  defined  some  place  else  by  a diferent  name.  The 
definition  b in  all  other  respects  the  szune.  Thb  b done  by: 

MAP  NODE  FROM  POINT; 

Eiro.MAP; 

which  simply  allows  an  application  to  call  Point  by  a more  familiar  name. 

Even  though  the  declaration  b caUed  Map  an  Entity  declaration  b created  in  the  current 
schema  block.  Using  a map  is  preferable  to  duplicating  an  entity  (with  appropriate  changes] 
since  mapping  establbhes  the  logical  connection  between  the  two  entities. 

A. 11. 5 Rule 

Description 

A Where  clause  in  an  entity  declaration  provides  a set  of  constraints  that  apply  within  a given 
entity  instance.  The  Rule  permits  the  definition  of  constraints  on  the  model  as  a whole. 

Syntax 


243  RULE-DECL  - RULE  RULE- ID  FOR  NESTED- ID -LIST  SEMICOLON 
ACTION-BODY  END-RULE  SEMICOLON  . 

The  rule  header  names  the  rule  and  specifies  the  entities  affected  by  the  rule.  This  statement 
b similar  to  a formal  parameter  list  except  the  "parameters”  are  themselves  entity  types.  Each 
of  the  entity  types  is  regarded  as  a set  of  instances  of  that  type;  i.e.,  the  entity  set  that  makes 
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up  a model. 


The  body  of  the  rule  is  much  like  the  body  of  a function  or  procedure.  The  chief  difference  is 
that  the  'end  state”  of  a rule  is  to  indicate  whether  or  not  some  global  constraint  is  satisfied. 
The  rule  is  satisfied  if  upon  termination,  the  violation  built-in  procedure  never  was  executed. 

Examples 


The  following  rule  declares  that  for  each  point  in  the  first  octant,  there  must  be  a point  in  the 
seventh  octant. 


RULE  PQINT.MATCH  FOR  (POINT) ; 

LOCAL 

Kl,  K2  : INTEGER: 

END .LOCAL; 

K1  :•  0: 

K2  0: 

REPEAT  FOR  EACH  POINT  IN  MODEL; 

IF  ( (POINT. X>0)  AND  (POINT. T>0)  AND  (POINT. Z>0))  THEN 
K1  Kl+l; 


END.IF; 

IF  ((POINT. X<0)  AND  (POINT. T<0)  AND  (POINT. Z<0))  THEN 
K2  K2+1: 


END.IF; 

END .REPEAT; 

IF  (K10K2)  THEN 
VIOUTION; 


END.IF; 
END .RULE; 


A. 11. 6 Algorithms 

An  algorithm  is  a sequence  of  statements  that  produces  some  desired  end  state.  The  two  kinds 
of  algorithms  that  can  be  specified  are  procedures  and  functions  (a  rule  is  also  an  algorithm, 
but  is  discussed  separately). 


Formal  parameters  define  the  input  to  the  algorithm.  When  the  algorithm  is  called,  actual  pa- 
rameters provide  actual  values.  The  actual  parameters  must  agree  in  type,  order,  and  number 
with  the  formal  parameters. 

Declarations  local  to  the  algorithm  are  given  following  the  header.  These  declarations  can  be 
types,  local  variables,  other  algorithms,  etc.  as  needed. 


The  body  of  the  algorithm  follows  local  declarations. 


A. 11. 6.1  Parameters 
Description 
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A Function  or  Procedure  can  have  formal  parameters.  Each  formal  parameter  has  a name 
and  a type.  The  name  is  treated  as  an  identifier  that  is  unique  within  the  scope  of  the  function 
or  procedure.  A formal  parameter  can  also  be  declared  as  var  (variable),  which  means  that  if 
the  parameter  is  changed  within  the  function  the  change  is  apparent  to  the  point  of  invocation. 
Parameters  not  declared  as  var  can  be  changed  also,  but  the  change  will  not  be  aparent  when 
control  is  returned  to  the  caller. 

Syntax 


208  FORMAL-PARAMETER  - [ VAR  ] ID-LIST  COLON  PARAMETZR-CAN-BE  . 


Examples 


FUNCTION  dist (pi .p2 :point) :real  ; 

PROCEDURE  aidpt (pi ,p2: point : var  result :polnt)  ; 

A. 11. 6. 2 Local  Variables 
Description 

A Local  variable  has  the  same  scope  as  a formal  parameter  and  exists  only  within  the  algorithm 
in  which  it  is  declared.  A local  variable  can  be  assigned  a value  or  can  participate  in  an 
expression. 

Syntax 


226  LOCAL-DECL  • LOCAL  { LOCAL-BODY- ITEM  } END-LOCAL  SEMICOLON  . 

224  LOCAL-BODY- ITEM  - ID-LIST  COLON  LOCAL-CAN-BE  [ INITIALIZER  ] SEMICOLON  . 

225  LOCAL-CAN-BE  - AGGREGATION-TYPE  I BASE-TTPE  I DEFINED-TTPE 
I ENTITY-TYPE  . 

181  AGGREGATION-TYPE  - AGGREGATE-TYPE  I ARRAY-TYPE  I LIST-TYPE  I SET-TTPE  . 
180  AGGREGATE-TYPE  - AGGREGATE  LIMIT-SPEC  OF  [ UNIQUE  ] ATTRIBUTE -CAN -BE  . 

222  LIMIT-SPEC  • LEFT-BRACKET  EXPRESSION  COLON  ( EXPRESSION 
I INFINITY  ) RIGHT-BRACKET  . 

182  ARRAY-TYPE  • ARRAY  INDEX-SPEC  OF  [ OPTIONAL  ] [ UNIQUE  ] 
ATTRIBUTE-CAN-BE  . 

218  INDEX-SPEC  - LEFT-BRACKET  EXPRESSION  COLON  EXPRESSION 
RIGHT-BRACKET  . 

223  LIST-TYPE  - LIST  LIMIT-SPEC  OF  [ UNIQUE  ] ATTRIBUTE-CAN-BE  . 

247  SET-TYPE  ■ SET  [ LIMIT-SPEC  ] OF  ATTRIBUTE-CAN-BE  . 

186  BASE-TYPE  ■ INTEGER-TYPE  I LOGICAL-TYPE  I NUMBER-TYPE  I 
REAL-TYPE  I STRING-TYPE  . 

220  INTEGER-TYPE  ■ INTEGER  [ PRECISION-SPEC  ] . 

233  PRECISION-SPEC  • LEFT-PAREN  EXPRESSION  RIGHT-PAREN  . 

227  LOGICAL-TYPE  • LOGICAL  . 

231  NUMBER-TYPE  - NUMBER  . 
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237  REAL-TTPE  • REAL  [ PRECISION-SPEC  ] . 

262  STRING-TTPE  - STRING  [ PRECISION-SPEC  ] [ VARTING  ] . 

210  INITIALIZER  - ASSIGNMENT -OPERATOR  EXPRESSION  . 

When  an  algorithm  is  activated,  numbers  are  initialized  to  zero,  strings  are  empty,  logicals  are 
False  and  lists  and  sets  are  empty  unless  an  initializer  is  explicitly  given.  The  initializer  value 
is  given  to  the  local  variable  upon  entry  to  the  algorithm. 

A. 11.6. 3 Procedure 

Description 

A Procedure  is  an  algorithm  that  receives  parameters  &om  the  point  of  invocation,  operates 
on  those  parameters  in  some  manner  to  produce  the  desired  end  state.  The  value  of  those 
parameters  might  be  changed.  A given  parameter  can  be  altered  only  if  the  Var  attribute  is 
present  for  that  parameter. 

Syntax 


235  PROCEDURE-DECL  - PROCEDURE  PROCEDURE- ID  [ FORKAL-PARAMETER-LIST  ] 
SEMICOLON  ACTION-BODY  END-PROCEDURE  SEMICOLON  . 

A. 11.6.4  Function 
Description 

A Function  is  an  algorithm  that  operates  on  parameters  and  produces  a specific  result  type. 
The  invocation  of  a function  is  equivalent  to  having  a variable  of  that  result  type  at  the  point 
of  invocation. 


Syntax 


211  FUNCTION-DECL  • FUNCTION  FUNCTION-ID  [ FORMAL-PARAMETER-LIST  ] 

COLON  RESULT-CAN-BE  SEMICOLON  ACTION-BODY  END-FUNCTION  SIMICOLON  . 


funetion-id  is  the  name  of  the  function,  formal-parameter-list  is  zero  or  more  parameters  sup- 
plying values  for  the  function  to  operate  on.  result-ean-be  is  the  result  produced  by  the  function. 

A Return  statement  is  used  to  pass  the  function  result  to  the  point  of  invocation.  Return  also 
terminates  the  function.  It  is  illegal  to  terminate  a function  except  by  a return  statement  with 
an  argument. 
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A. 11. 6. 5 Executable  Statements 

The  executable  statements  are  Assignment  Case  Compound  Escape  If  Procedure  call 
Repeat  Return  Skip  and  With. 

Executable  statements  can  appear  only  within  an  execution  block. 

An  executable  statement  can  be  just  a semicolon,  in  which  case  it  is  called  a null  statement. 
Examples 


IF  A • 13  THEN 

; --  this  is  a null  stateaent. 

ELSE 
B 6 ; 

END.IF  : 

Syntax 


251  STATEMENT  • ASSIGNMENT -STATEMENT  I CASE -STATEMENT 

I COMPOUND -STATEMENT  I DUMMY -STATEMENT  I ESCAPE- STATEMENT 
I IF-STATEMENT  I PROCEDURE-CALL-STATEMENT  I REPEAT-STATEMENT 
I RETURN -STATEMENT  I SKIP -STATEMENT  I WITH- STATEMENT  . 

183  ASSIGNMENT-STATEMENT  - ID  ASSIGNMENT-OPERATOR  EXPRESSION 
SEMICOLON  . 

101  CASE -STATEMENT  - CASE  EXPRESSION  OF  CASE-BLOCK  END-CASE 
SEMICOLON  . 

189  CASE-BLOCK  • CASE-ACTION  { CASE-ACTION  } [ CASE-OTHERWISE  ] . 

188  CASE-ACTION  - EXPRESSION  < COMMA  EXPRESSION  } COLON  STATEMENT  . 

190  CASE-OTHERWISE  ■ OTHERWISE  COLON  STATEMENT  . 

192  COMPOUND -STATEMENT  - BEGIN  < STATEMENT  } END  SEMICOLON  . 

198  DUMMY -STATEMENT  - SEMICOLON  . 

202  ESCAPE-STATEMENT  - ESCAPE  SEMICOLON  . 

215  IF-STATEMENT  - IF  EXPRESSION  THEN  STATEMENT  { STATEMENT  } 

C ELSE  STATEMENT  < STATEMENT  } ] END -IF  . 

239  REPEAT -STATEMENT  - REPEAT  < REPEAT -CONTROL  } SEMICOLON 
< STATEMENT  } END-REPEAT  SEMICOLON  . 

241  RETURN -STATEMENT  - RETURN  [ LEFT-PAREN  EXPRESSION  RIGHT-PAREN  ] 
SEMICOLON 

250  SKIP-STATEMENT  • SKIP  SEMICOLON  . 

268  WITH-STATEMENT  - WITH  ID  STATEMENT  . 


A. 11. 6. 5.1  Assignment  Statement 
Description 
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The  aasignment  itatement  is  used  to  assign  a value  to  a variable. 

Syntax 

183  ASSIGNMENT-STATEMENT  ■ ID  ASSIGNMENT -OPERATOR  EXPRESSION  SEMICOLON  . 
Examples 


LOCAL 

A.  B.  C : INTEGER  ; 

END .LOCAL  ; 

A 1 : 

B 2 ; 

C :•  A+B  ; 

A. 11. 6. 5. 2 Assignment  Compatibility 

An  expression  can  be  assigned  to  a variable  only  when  the  type  of  the  expression  is  compatible 
with  the  type  of  the  variable.  Types  can  be  compatible  without  being  identical.  Types  are 
assignment  compatible  when: 

1.  The  types  are  the  same.  Different  user  defined  types  are  never  the  same  even  if  their  base 
types  are  the  same. 

2.  One  type  is  a subtype  of  the  other  type;  e.g.,  integers  and  reals  are  subtypes  of  number, 
and  integer  is  a subtype  of  real. 

3.  Both  types  are  strings. 

4.  Both  types  are  arrays  where  the  bounds  and  the  base  types  are  identical. 

5.  Both  types  are  lists  with  identical  base  types. 

6.  Both  types  are  sets  with  identical  base  types. 

A. 11.6. 5. 3 Case  Statement 
Description 

The  Case  statement  causes  the  selection  and  execution  of  many  possible  statements  depending 
on  the  value  of  a selector  expression.  The  case  statement  consists  of  an  expression,  which  is 
the  case  selector,  and  a list  of  alternative  actions,  each  one  preceded  by  a case  label.  The  type 
of  the  case  label  must  agree  with  the  type  of  the  case  selector.  The  statement  having  the  case 
label  that  matches  the  value  of  the  case  selector  is  executed.  If  none  of  the  case  labels  match 
the  value  of  the  case  selector  then: 


1.  if  the  Otherwise  clause  is  present  the  statement  associated  with  otherwise  is  executed. 


60 


N287 


2.  if  the  Otherwise  clause  is  not  present  no  statement  (in  the  CASE)  is  executed. 
Syntax 


ICl  CASE -STATEMENT  ■ CASE  EXPRESSION  OF  CASE-BLOCK  END-CASE  SEMICOLON 
180  CASE-BLOCK  ■ CASE-ACTION  { CASE-ACTION  } [ CASE -OTHERWISE  ] . 

188  CASE-ACTION  ■ EXPRESSION  < COMMA  EXPRESSION  } COLON  STATEMENT  . 
100  CASE -OTHERWISE  ■ OTHERWISE  COLON  STATEMENT  . 


Examples 


LOCAL 

a : integer  ; 
X : real  ; 
END.LOCAL  ; 


a 3 : 

X 34.07  ; 

CASE  a OF 


1 : 

: X :■  sinCx)  : 

2 

: X :■  exp(x)  ; 

3 : 

: X :■  sqrt(x)  ; 

--  This  is  executed! 

4 

: X :■  log(x)  : 

END.CASE  : 


Restrictions: 


• The  type  of  the  expression  following  ease  must  agree  with  the  expression  that  is  part  of 
the  ease^aetion. 

• Only  one  otherwise  case-action  can  be  given.  It  must  be  the  last  case-action  if  it  appears 
at  all. 

• Each  case  label  must  be  different.  However,  it  is  possible  that  two  case  label  expressions 
will  evaluate  the  same.  In  that  event,  the  6rst  reading  from  top  to  bottom  will  be  executed. 


A. 11. 6. 5. 4 Compound  Statement 
Description 

The  compound  statement  is  a sequence  of  statements  delimited  by  Begin  and  End.  A com- 
pound statement  is  treated  as  a single  logical  statement. 

Syntax 


102  COMPOUND -STATEMENT  • BEGIN  { STATEMENT  } END  SEMICOLON  . 
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Example* 

BEGIN 

A ■ i+1  ; 

IF  A > 100  THEN 
A 0 : 

END.IF; 

END  ; 

A. 11. 6. 5. 5 Escape  Statement 
Description 

Escape  causes  an  immediate  transfer  to  the  statement  following  the  end  of  the  block  in  which 
it  appears.  Note  that  this  is  the  only  way  an  indefinite  repeat  can  be  terminated. 

Syntax 


202  ESCAPE -STATEMENT  - ESCAPE  SEMICOLON  . 
Examples 


REPEAT  UNTIL  (A-l); 

IF  (A<0)  THEN 
ESCAPE; 

END.IF; 

END .REPEAT; 

A. 11. 6. 5. 6 If  Then  Else  Statement 
Description 

The  If  statement  provides  for  the  conditional  execution  of  a statement  according  to  the  value 
of  a logical  (true  or  false)  expression.  The  statement  following  Then  is  executed  when  the 
logical  expression  evzduates  to  True.  When  the  expression  evaluates  to  False  the  statement 
associated  with  Else  is  executed. 

The  Else  clause  b optional  however.  If  an  else  clause  b not  present,  and  the  result  of  the  logical 
expression  b False  then  the  if  statement  has  no  effect. 

Syntax 


When  executed,  control  pi 
alter  END .REPEAT. 


to  the  stateoent 
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216  IF-STATEMENT  • IF  EXPRESSION  THEN  STATEMENT  < STATEMENT  > 
C ELSE  STATEMENT  { STATEMENT  } ] END- IF  . 


Examples 


LOCAL 

A : INTEGER  ; 

END .LOCAL  ; 

1 • 6 ; 

IF  A < 10  THEN 

A • A+1  ; --  THIS  STATEMENT  WILL  BE  EXECUTED. 
ELSE 

A - A-1  : 

END.IF  : 

A. 11.6. 5. 7 Procedure  Call  Statement 


Description 


The  Procedure  call  statement  activates  a procedure.  The  statement  consists  of  a procedure 
identifier  followed  by  an  actual  parameter  list  (which  can  be  empty).  The  number  and  type  of 
the  actual  parameters  must  agree  with  the  formal  parameters  defined  for  that  procedure. 

Syntax 


234  PROCEDURE-CALL-STATEMENT  - PROCEDURE- ID  [ ACTUAL-PARAMETER-LIST  ] 
SEMICOLON  . 

Examples 


The  following  procedure  header  defines  two  formal  parameters;  A,  which  is  an  integer  variable, 
and  B,  which  is  a real.  The  actual  parameters  used  with  any  call  to  this  procedure  must  agree 
in  number  and  type. 

PROCEDURE  XXX (VAR  A: INTEGER;  BrREAL)  ; 


The  following  procedure  calls  show  both  valid  and  invalid  cases. 


IXX(1,2);  (•  Invalid  since  the  first  actual  paraneter  is  not  a 

variable  *) 

XXX(a,  37);  (•  This  is  a valid  procedure  call  (assuaing  that  a is 

typed  as  an  integer).  The  second  actual  parameter, 
although  not  a real,  is  valid  since  a type  conversion  takes 
place  automatically  *) 


XXX(a) : 


(•  This  call  is  not  valid  since  the  correct  number  of 
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actual  paraaetera  it  not  given  •) 

XZ2(a.2.0.3) : (*  Invalid,  too  aanj  actual  paraaetera  •) 

A. 11.6. 5. 8 Repeat  Statement 
Deacription 

The  Repeat  block  is  used  to  repeat  a sequence  of  statements.  The  controlling  conditions  are 
finite  iteration,  while  a condition  is  true,  until  a condition  is  true,  and  indefinite  repetition. 
These  controls  can  be  used  in  combination  to  specify  the  conditions  that  terminate  the  repeat 
block. 

Syntax 


230  REPEAT-STATE?^!  - REPEAT  { REPEAT-CONTROL  } SEMICOLON 
{ STATEMENT  } END-REPEAT  SEMICOLON  . 


Note  - The  repeat  controls  can  be  given  in  any  order,  but  the  same  kind  of  control  cannot  be 
given  more  than  once. 

A. 11.6. 5.9  Until  Control 
Deacription 

Causes  the  block  to  repeat  Until  the  expression  is  true.  The  expression  will  be  evaluated  after 
each  iteration.  At  least  one  iteration  will  always  be  executed. 

Syntax 


264  UNTIL-CONTROL  - UNTIL  EXPRESSION  . 

A. 11. 6. 5. 10  While  Control 

Deacription 

Causes  the  block  to  repeat  While  the  expression  is  true.  The  expression  will  be  evaluated 
before  each  iteration.  If  the  expression  is  fabe  initially,  the  block  will  not  be  executed. 

Syntax 


267  WHILE-CONTROL  - WHILE  EXPRESSION  . 
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A.11.6.5.11  Increment  Control 
Description 

Causes  the  block  to  repeat  while  the  active  variable  lies  in  the  given  interval.  The  active 
variable  is  initialized  as  the  first  bounding  condition.  After  each  iteration  the  active  variable  is 
incremented  (or  decremented)  as  specified.  Before  each  iteration,  the  test: 

{ expreaaionl  <•  actlve-var  <■  •3cpre8sion2  } 

is  evaluated.  The  block  is  executed  only  when  this  test  yields  true,  expressions,  if  present, 
updates  the  value  of  the  active  variable  after  each  iteration.  If  exprMsionS  is  omitted,  the 
active  variable  is  updated  by  one  (1). 

Syntax 

217  INCREMENT-CONTROL  • LOCAL- ID  ASSIGNMENT-OPERATOR  EXPRESSION  TO 
EXPRESSION  [ BT  EXPRESSION  ] . 

A. 11.6. 5. 12  Return  Statement 
Description 

The  Return  statement  terminates  the  execution  of  a function  or  procedure.  A function  return 
must  include  an  expression,  which  is  the  result  returned  to  the  point  of  invocation.  The  ex* 
pression  must  be  the  same  type  as  the  declared  type  of  the  function.  A procedure  return  must 
not  include  an  expression. 

Syntax 

241  RETURN -STATEMENT  ■ RETURN  [ LEFT-PAREN  EXPRESSION  RIGHT-PAREN  ] SEMICOLON 
Examples 


RETURN(50)  : (*  from  a function  •) 

RETURN(«ork.point)  ; 

RETURN  : (*  froa  a procedure  *) 

A. 11.6. 5. 13  Skip  Statement 


Description 

Skip  causes  an  immediate  transfer  to  the  end  of  the  block  in  which  it  appears.  If  the  block  is 
a repeat  block,  the  terminal  conditions  are  tested.  The  block  will  be  repeated  or  terminated 
based  on  evaluation  of  the  repeat  controls. 

Syntax 
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260  SKIP -STATEMENT  - SKIP  SEMICOLON  . 


Examples 


REPEAT  UNTIL  (A*l): 

IF  (A<0)  THEN 

SKIP;  (*  When  execntsd,  control  passes  to  the  END .REPEAT 

stateoent  where  the  terninal  condition  is 
eralnated.  *) 

END.IF; 

END .REPEAT; 


A. 11.6. 5. 14  With  Statement 


Description 

The  With  statement  provides  a partial  variable  qualification  that  simplifies  the  writing  of 
separate  components  of  a complex  object,  i.e.,  an  entity.  The  with  statement  starts  with  the 
keyword  With  followed  by  a partial  qualification,  followed  by  a statement. 

Syntax 

268  WITH-STATEMENT  - WITH  ID  STATEMENT  . 

Examples 


local 

a : point  ; (*  point  has  attributes  x,  j.  and  z *) 

b : number  ; 
end. local  ; 

WITH  a 
begin  ; 

b :•  X y ♦ z ; (•  sane  as;  a.x  ♦ a.y.  ♦ a.z  •) 

end  ; 
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Expressions  sre  m&de  up  of  operators  and  operands.  Operuids  must  be  compatible  with  opera- 
tors. Binary  operators  require  two  operands  and  the  operator  appears  between  those  operands. 
A unary  operator  requires  only  one  operand,  which  is  given  before  the  operand. 

There  are  three  kinds  of  expressions. 


• Arithmetic  expressions  accept  numeric  operands  and  produce  a numeric  result. 

• Relational  expressions  accept  various  kinds  of  operands  and  produce  a logical  (true  or 
false)  result. 

• String  expressions  accept  string  operands  and  produce  a string  result. 

Operators  have  computational  precedence  as  defined  below.  Evaluation  proceeds  &om  left  to 
right  with  the  highest  precedence  being  evaluated  first. 


Operator  Precedence 

1 Unary  operators  ♦ - not 

2 Exponentiation  •* 

3 Multiplication  and  Division  * / div  nod  and 

4 Addition  and  Subtraction  * or  II 

5 Relational  ■<><■>■><  :<>: 

in  like  cardinality 


An  operand  between  two  operators  of  different  precedence  is  bound  to  the  operator  with  the 
higher  precedence,  e.g.,  «10*20  or  (-10)*20. 

An  operand  between  two  operators  of  the  same  precedence  is  bound  to  the  one  on  the  left,  e.g., 
10/20*30  or  (10/20)*30 

Expression  enclosed  by  parentheses  are  evaluated  before  being  treated  as  a single  operand. 
Syntax 


20e  EXPRESSION  • SIMPLE-EXPRESSION  < RELATIONAL-OPERATOR-EXTENDED 
SIMPLE-EXPRESSION  } . 

248  SIMPLE -EXPRESS I ON  - [ SIGN  ] TERM  < ADDITION -LIKE- OPERATIONS  TERM  > . 
259  TERM  « FACTOR  { MULTIPLICATION-LIKE-OPERATIONS  FACTOR  } . 

207  FACTOR  • SIMPLE-FACTOR  [ EXPONENT I AT I ON -OPERATOR  SIMPLE-FACTOR  ] . 

240  SIMPLE-FACTOR  - LITERAL  I FUNCTION-CALL  I ID  I SET-CONSTRUCT 
I LEFT-PAREN  EXPRESSION  RIGHT-PAREN  I INTERVAL  I NOT-OPERATOR 
SIMPLE-FACTOR  . 
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A. 12.1  Arithmetic  Expressions 

Description 

The  arithmetic  operations  are  add  (+),  subtract  (-),  divide  (/),  integer  divide  (D/V),  multiply 
(•),  exponentiation  (•*),  and  modulo  [MOD).  Both  operands  must  be  numbers  and  the  result 
is  a number. 

The  type  of  the  result  of  these  operations,  based  on  the  type  of  the  operands,  is: 


1 Operation 

Ope rand 'Types 

Result -Type 

1 

1 

1 4 

Add 

real 

real 

1 

integer 

integer 

1 

1 

integer,  real 

real 

1 

1 • 

Subtract 

real 

real 

1 

1 

integer 

Integer 

1 

1 

1 ---- 

integer,  real 

real 

1 

1 

1 • 

Multiply 

real 

real 

1 

1 

integer 

integer 

1 

1 

1 

integer,  real 

real 

1 

1 

1 / 

Divide 

real 

real 

1 

1 

integer 

real 

1 

1 

1 

integer,  real 

real 

1 

1 DIV  Integer  Divide 

real 

integer 

1 

1 

integer 

integer 

1 

1 

integer .real 

integer 

1 

1 • • • 

1 MOD 

Modulo 

integer 

integer 

1 

1 

(remainder) 

real 

integer 

1 

1 

1 

integer,  real 

integer 

1 

1 

1 ** 

Exponentiation  integer 

integer 

1 

1 

real 

real 

1 

1 

integer .real 

real 

1 

1 

4.-... 

real. integer 

real 

1 

* Real  operands  are  first  truncated  to  integers. 
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A. 12. 2 Relational  Expressions 
Description 

The  T&lue  relational  operators  are  equal  ( ■)  , not  equal  ( o)  , greater  than  ( >)  , leas  than  ( 
<}  , greater  than  or  equal  ( >■)  , less  than  or  equal  ( <■)  , Kt  mttbership  ( In)  , and  string 
match  ( lilt)  . 

The  instance  relational  operators  are  instance  equal  ( : ■ : ) and  instance  not  equal  ( : <> : ) . 

The  cardinality  relational  operator  has  the  form  [ expression  : expression  ] . 

The  two  operands  must  be  compatible;  e.g.,  a string  cannot  be  compared  to  a nmnber  in  this 
manner. 

The  result  of  a relational  expression  is  a logical  value  true  or  false.  The  not  operator  may 
precede  the  operation  to  reverse  the  result. 

Examples 


27  < 84  (*  true  *) 

HOT  (27  < 84)  (*  false  •) 

A. 12.3  Interval  Expressions 
Description 

An  interval  expression  tests  whether  or  not  a value  falls  within  a given  interval  yielding  a TVue 
or  False  result. 

Syntax 


221  INTERVAL  - LEFT-CURL  EXPRESSION  RELATIONAL-OPERATOR  EXPRESSION 
RELATIONAL-OPERATOR  EXPRESSION  RIGHT-CURL  . 


Examples 


IF  { 10  <» 


A < MAXVAL  } THEN 
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A. 12.4  String  Expressions 

Description 

The  only  string  operation  is  string  concatenation  represented  by  the  1 1 symbol.  Both  operands 
must  be  strings  and  the  result  of  a concatenation  is  also  a string. 

Examples 

aaae  :■  last.naae  II  ' ’ II  llrst.naae  ; 

A. 12. 5 Function  Call 

Description 

The  function  call  activates  a function.  It  consists  of  a function  identifier  possibly  followed  by 
an  actual  parameter  list.  The  number  and  type  of  the  actual  parameters  must  agree  with  the 
formal  parameters  defined  for  that  function. 

A function  call  can  be  qualified  when  the  function  returns  some  kind  of  aggregate  type,  "dot” 
qualification  allows  you  to  access  individual  attributes  when  the  return  type  is  an  entity  type. 
Subscript  notation  can  be  used  when  the  return  type  is  an  array,  list,  or  set  type. 

Examples 

ENTITY  POINT; 

X.  Y.  2 : NUMBER; 

END .ENTITY; 

FUNCTION  MIDPOINT.OF.LINE (L: LINE) : POINT; 

END .FUNCTION; 

IF  MIDPOINT.OF .LINE (L506) .1-0.0  THEN 
END.IF; 

Syntax 


210  FUNCTION-CALL  - FUNCTION-ID  [ ACTUAL-PARAMETER-LIST  ] { QUALIFICATION  } . 
236  QUALIFICATION  - { SUBSCRIPT  } [ DOT  ID  ] . 

Examples 


a :•  11(1.2,3)  ; 
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A. 12.6  Set  Construct 

The  set  construct  is  used  to  establish  a set  value. 

Syntax 


240  SET-CONSTRUCT  - LEFT-BRJLCEET  [ EXPRESSION  < COMMA  EXPRESSION  > ] 
RIGHT-BRACKET  . 

Examples 

Given  the  declaration: 

a : set  of  integer: 


a value  can  be  assigned  as: 


a :-  [ 1.  3.  0.  0*8.  -12  ] ; 
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A. 13  Express  Specification 

The  form&l  definition  of  the  Express  Language  is  given  in  this  section.  This  specification  is 
organized  as  follows: 

• Syntax  of  the  specification 

• Cross  reference  for  rules 

• Rules 

A. 13.1  The  Syntax  of  the  Specification 

Regular  expressions  define  the  tokens  of  the  Express  language  and  the  statements  that  can 
legally  be  constructed  from  those  tokens.  Tokens  are  composed  of  characters;  statements  are 
composed  of  tokens.  Tokens  can  be  constants  or  variables.  For  example,  keywords  and  punc- 
tuation are  token  constants  and  identifiers  and  literals  are  token  variables. 

The  general  form  of  a regular  expression  is: 


name  ■ expression  . 
where 


nane 


expression 

name 


i»  n 

I 

[element] 

{element} 

(element) 


is  the  symbolic  name  given  to  expression  where  the  name  is  made  up 
entirely  of  letters,  digits,  or  the  dash  (-)  character, 
is  the  assignment  of  a regular  expression  to  a name 
is  some  valid  regular  expression  composed  from  the  following  ele- 
ments: 

is  a token  or  statement  defined  somewhere  in  the  specification  ac- 
cording to  the  definition  given  above. 

is  the  character  x or  X (case  insensitive).  For  example,  ’xy’  is  the 
string  xy,  xY,  Xy,  or  XY  (case  insensitive), 
is  the  character  ’ 

is  the  choice  operator,  e.g.,  ’x’|’y’  means  either  x or  y 
means  element  occurs  zero  or  one  times 
means  element  occurs  zero  or  many  times 

groups  the  element(s)  enclosed  by  parentheses,  e.g.,  ’x’(’y’l’z’)  means 
xy  or  xz. 

the  period  terminates  a production. 


The  following  are  system  dependent  characters  or  character  sets.  For  example,  \t  is  the  Tab 
character,  which  may  or  may  not  have  meaning  to  a particular  system. 

\a  is  any  printable  ASCII  character. 

\n  is  the  newline  character 
\q  is  the  quote  (’)  character. 

\t  is  the  tab  character 
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ABS  1 I BUILT- IN-FUNCTIOH-NiME(  137) 

ICOS  2 I BUILT- IN-FTmCTION-HAME(  137) 

ICTION-BODT  178  I FWCTI0K-DECL(211)  PR0CEDUEE-DECL(235) 

EULE-DECL(243) 

ACTUiL-PARAMETER-LIST  170  | rUKCTI0N-CALL(21O) 

PROCEDURE-CALL-STATEMENT (234) 

ADDITION-LIKE-OPERATIONS 134  i SIMPLE-EXPR£SSI0N(248) 

AGGREGATE  3 I AGCREGATE-TTPEClSO) 

GENERAL- AGGREGATION (212) 

AGGREGATE-TTPE  180  I AGGREGATI0N-TTPE(181) 

AGGREGATION-TTPE  181  I ATTRIBUTE-CAN-BE(185)  L0CAL-CAN-BE(225) 

TTPE-CAN-BE(260) 

AND  4 I AND-0PEaAT0R(135) 

AND-OPERATOR  135  I MDLTIPLICATI0N-LIKE-0PERATI0NS(164) 

SUPERTTPE-EIPRESSION (257 ) 

ARRAY  5 I ARRAT-TTPE(182)  GENERAL- AGGREGATION (212) 

ARRAY-TYPE  182  I AGGREGATION-TYPE (181) 

AS  6 I RETYPE-DECL(242) 

ASIN  7 I BDILT-IN-FUNCTI0N-NAME(137) 

ASSIGNMENT-OPERATOR  8 I ASSIGNMENT-STATEMENT(183) 

INCREMENT-C0NTR0L(217)  INITIALIZER (219) 

ASSIGNMENT-STATEMENT  183  I STATEMENT (251) 

ASSUME  0 I ASSUME-DIRECTIVE(184) 

ASSUME-DIRECTIVE  184  I DIRECTIVE (107) 

ATAN  10  I BUILT- IN-rUNCTION-NAME(  137) 

ATTRIBUTE-CAN-BE  185  | AGGREGATE-TYPE (180)  ARRAY-TYPE (182) 

EIPLICIT-ATTRIBUTE(203)  LIST-TYPE (223) 
RETYPE-DECL(242)  SET-TYPE(247) 

ATTRIBUTE- ID  136  I DERIVED- ATTRIBUTE( 105) 

BASE-TYPE  186  I ATTRIBUTE-CAN-BE (186)  L0CAL-CAN-BE(225) 

PARAMETER-CAN -BE (232)  RESULT-CAN-BE(240) 
TTPE-CAN-BE(260) 

BEGIN  11  I COMPOUND-STATEMENT (192) 

BLOCK-MEMBER  187  I ACTI0N-B0DY(178)  SCHEMA -DECL( 244) 

BUILT- IN-FUNCTION-NAME  137  I FUNCTION- ID (147) 

BUILT- IN-PROCEDURE-NAME  138  I PROCEDURE -ID (168) 

BY  12  I INCREMENT-C0NTR0L(217) 

CARDINALITY- OPERATOR  130  I REUTI0NAL-0PERAT0R-EITENDE?(171) 

CASE  13  I CASE-STATD<ENT(101) 

CASE-ACTION  188  I CASE-BL0CK(180) 

CASE-BLOCK  189  I CASE-STATEMENT (101) 

CASE-OTHERWISE  100  I CASE-BLOCK (180) 

CASE-STATEMENT  191  I STATEMENT (251) 

COLON  14  I -CASE-ACTIONdSS)  CASE -OTHERWISE (190) 
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DERIVED-ATTRIBUTEC 19B) 
EIPLICIT-ATTRIBUTE(203) 
F0RMAL-PARAMETEE(2O8)  FUNCTI0N-DECL(211) 
INDEX- SPEC (21 8)  LIMIT-SPEC (222) 
L0CAL-BQDT-ITEM(224)  EETT?E-DECL(242) 

COMMA  16  I ACTUAL-PARAMETER-LIST  (170) 

ASSnME-DIR£CTIVE(184)  CA5E-ACTI0H(188) 
ID-LIST(214)  SET-CONSTRUCT (246) 

COMPOUND -STATEMENT  102  I STATEMENT (251) 

CONCATENATION -OPERATOR  16  I ADDITION-LIKE-OPERATIONS (134) 

CONSTANT  140  I LITERAL (168) 

COS  17  I BUILT- IN-FDNCTION-NAME(  137) 

DEFINE  18  I DEFINE-DIRECTIVE(103) 

DEFINE-DIRECTIVE  103  I DIRECTIVE (107) 

DEFINED-TYPE  104  I ATTRIBUTE-CAN-BE(186)  L0CAL-CAN-BE(225) 

PARAMETER-CAN-BE(232)  RESULT-CAN-BE(240) 
TTPE-CAN-BE(260) 

DEFINED-TYPE- ID  141  I DEFINE-DIRECTIVE(103)  DEFINED-TYPE(104) 

TTPE-ITEM(262) 

DERIVE  10  I DERIVED-ATTRIBUTE-DECL(106) 

DERIVED-ATTRIBUTE  105  I DERIVED-ATTRIBUTE-DECL(106) 

DERIVED-ATTRIBUTE-DECL  106  I ENTITY-DECL(IOO) 

DIGIT  142  I ID-CHAR(140)  INTEGER-LITmAL(166) 

DIRECTIVE  107  I BLOCK-MEMBER (187) 

DIV  20  I INTEGER-DIVIDE-0PERAT0R(164) 

DIVIDE-OPERATOR  143  I MULTIPLICATION-LIKE-OPERATIONS (164) 

DOT  21  I ID-QUALIFIED (161)  REAL-LITERAL(160) 

QUALIFICATION (236) 

DUMMY -STATEMENT  108  I STATEMENT (251) 

DYNAMIC  22  I EXPLICIT-ATTRIBUTE(203) 

ELSE  23  1 IF -STATEMENT  (21 6) 

EMBEDDED -REMARK  144  I REMARK(172) 

END  24  I C0MP0UND-STATEMENT(102) 

END-CASE  25  I CASE-STATD<ENT(101) 

END-ENTITY  26  I ENTITY-DEa(lOO) 

END-FUNCTION  27  I FUNCTI0N-DECL(211) 

END-IF  28  I IF-STATEMENT(215) 

END-LOCAL  20  I LOCAL -DECL( 226) 

END-MAP  30  1 MAP-DECL(228) 

END-PROCEDURE  31  I PROCEDURE -DECL( 235) 

END-REPEAT  32  I REPEAT-STATEMENT(230) 

END-RULE  33  I RULE-DECL(243) 

END-SCHEMA  34  1 SCHEMA-DECL(244) 

END-TYPE  35  1 TYPE-DECL(261) 

ENTITY  36  I ENTITY -DECL( 109) 

ENTITY-DECL  100  I BLOCK-MEMBER (187) 

ENTITY-ID  145  I ENTITY-DECL (199)  ENTITY-TYPE(200) 

MAP-DECL(228) 
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ENTITT-TTPE 200  I inEIBUTE-ClH-BEClBB)  L0ClL-CiN-BE(226) 

PAEAMETER-CiH-BE(232)  RESDLT-CiB-BE(240) 

ENUMEIUTION  37  I ENDMEBJLTION- TYPE (201) 

EMUMEEITION-TTPE  201  I TYPE- CIH- BE  (260) 

equal  38  I EQTJiL-0PEaAT0R(146)  TYPE-ITEM(262) 

EQUAL-OPERATOR  146  I 1EUTIONAL-OPERATOR(170) 

ESCAPE  30  I ESCAPE-STATEMEHT(202) 

ESCAPE-STATEMENT  202  I STATEMENT (261) 

EVERYTHING  40  I EXPORT-DIRECTIVE (206) 

EXCEPT  41  I EXP0RT-DI1ECTIVE(206) 

EXCLUSIVE-QR-OPERATOR  42  I 0R-0PERAT0R(166) 

EXISTS  43  I BUILT-IN-FDNCTI0N-HAME(137) 

EXP  44  I BUILT-IN-FDNCTI0N-BAME(137) 

EXPLICIT-ATTRIBUTE  203  I EXPLICIT-ATTRIBUTE-DECL(204) 

EXPLICIT- ATTRIBUTE -DECL  204  I ENTITT-DEa(lOO) 

EXPONENTIATION-OPERATOR  46  I FACTOR (207) 

EXPORT  46  I EXPQRT-DIRECTIVE(206) 

EXPORT-DIRECTIVE  206  I DIRECTIVE (107) 

EXPRESSION  206  I ACTDAL-PARAMETER-LIST(170) 


ASSIGNMENT-STATEMENT ( 183) 
CASE-ACTI0N(188)  CASE-STATEMENT (101) 
ir-STATEMENT(21B)  INCREMENT-CONTROL (217) 
INDEX-SPEC (218)  INITIALIZER (210) 
INTERVAL(221)  LIMIT-SPEC (222) 
PRECISION-SPEC (233) 

RETURN -STATEMENT (241)  SET-CONSTRUCT (246) 
SIMPLE-FACT0R(240)  SUBSCRIPT(2S3) 
UNTIL-CONTROL(264)  WHERE -RULE(266) 
WHILE-CONTROL (267) 


EXTERNAL  47  I EXPLICIT-ATTRIBUTE(203) 

FACTOR  207  | TERM(250) 

FALSE  48  I CONSTANT(140)  LOGICAL-LITERAL (160) 

FOR  40  I RULE-DECL(243) 

FORMAL-PARAMETER  208  I FORMAL-PARAMETER-LIST  (200) 

FORMAL-PARAMETER-LIST  200  I FUNCTI0N-DECL(211)  PR0CEDURE-DEa(235) 

FORMAT  60  I BUILT-IN-FUNCTI0N-NAME(137) 

FROM  51  I MAP-DECL(228) 

FUNCTION  62  I FUNCTI0N-DECL(211) 

FUNCTION-CALL  ..210  I SIMPLE-FACTOR (240) 

FUNCTION-DECL  211  I BLOCK -MEMBER (187) 

FUNCTION-ID  147  I FUNCTI0N-CALL(210)  FUNCTI0N-DECL(211) 

CENmL- AGGREGATION  212  \ PARAMETER-CAN-BE(232) 

GENERIC  63  I GENERIC-TYPE(213) 

GENERIC-TYPE  213  I PARAMETER-CAN-BE(232)  RESULT-CAN-BE(240) 

GREATER-EQUAL-OPERATOR  64  I RELATI0NAL-0PERAT0R(170) 

GREATER-THAN-OPERATOR  66  I RELATIONAL-OPERATOR(170) 

HIBOUND  66  I BDILT-IN-FUNCTI0N-NAME(137) 

ID  148  I ID-INDEXED(160)  L0CAL-ID(160) 

ASSI GNMENT- STATEMENT ( 1 83 ) 
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ID-CHAfi  140 

ID- INDEXED  160 

ID-LIST  214 


ID-QUILIFIED  161 

ID-SIMPLE  162 


IF  67 

IF -STATEMENT  216 

IN  68 

IN-OPERATOR  163 

INCLUDE  60 

INCLUDE-DIRECTIVE  216 

INCLUSIVE -OR -OPERATOR  60 

INCREMENT-CONTROL  217 

INDEX-SPEC  218 

INFINITY  61 

INITIALIZER  210 

INSERT  62 

INSTANCE -EQUAL -OPERATOR  63 

INSTANCE -NOTEQUAL- OPERATOR  64 

INTEGER  66 

INTEGER-DIVIDE-OPERATOR  164 

INTEGER-LITERAL  166 

INTEGER-TYPE  220 

INTERNAL  66 

INTERVAL  221 

LEFT-BRACKET  67 

LEFT-CURL  68 

LEFT-PAREN  60 


LESS-EQUAL-OPERATOR  70 

LESS -THAN -OPERATOR  71 


QUALIFICATION (236)  SIMPLE-FACT0R(240) 
WITH- STATDffiNT ( 268 ) 

I ID-SIMPLE(162) 

I ID-qUALIFIED(161) 

I EIPLICIT-ATTRIBUTE(203) 
FOBMAL-PARAMETEE (208 ) 

LOCAL-BODY- ITEM (224) 

NESTED- ID-LIST(230)  RETTPE-DECL(242) 
UNIQUE-RULE (263) 

I ID(148) 

I ATTRIBUTE-ID (136)  DEFINED-TTPE-ID(141) 
ENTITY-ID(146)  FUNCTION- ID (147) 

ID(148)  MAP-ID(161)  PROCEDURE -ID (168) 
EULE-ID(173)  SCHEMA -ID (174) 

ID-LIST(214)  SUPERTTPE-FACT0R(268) 

I IF-STATEMENT(216) 

I STATEMENT (261) 

I IN -OPERATOR (163) 

I REUTI0NAL-0PERAT0R-EXTENDED(171) 

I INCLUDE-DIRECTIVE(216) 

I DIRECTIVE(107) 

I OR -OPERATOR (166) 

I REPEAT- CONTROL (238) 

I ARRAY -TYPE (182) 

I LIMIT- SPEC (222) 

I DERIVED -ATTRIBUTE (106) 
L0CAL-B0DY-ITEM(224) 

I BUILT- IN-PROCEDURE-NAME (138) 

I RELATI0NAL-0PERAT0R(170) 

I REUTIONAL-OPERATOR(170) 

I INTEGER- TYPE (220) 

I DIVIDE-OPERATOR (143) 

I LITERAL(188)  REAL-LITERAL(160) 

I BASE-TYPE(186) 

I EXPLICIT-ATTRIBUTE(203) 

I SIMPLE-FACT0R(240) 

I INDEX- SPEC (218)  LIMIT-SPEC (222) 
SET-CONSTRUCT (246)  SUBSCRIPT (263) 

I INTERVAL (221) 

I ACTUAL-PARAMETER-LIST (170) 

ASSUME -D IRECT I VE ( 1 84 ) 
FORMAL-PARAMETER-LIST (200) 

NESTED- ID-LIST (230)  PRECISI0N-SPEC(233) 
RETURN - STATEMENT ( 24 1 ) 

SIMPLE-FACTOR (240)  SUPERTTPE-DECL(266) 
SUPERTYPE-FACTOR (258 ) 

I RELATI0NAL-0PERAT0R(170) 

I REUT I ONAL- OPERATOR  (170) 
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LETTER  166 

LIKE 72 

LIKE-OPERATOR  167 

LIMIT-SPEC  222 

LIST 73 

LIST-TTPE  223 

LITERAL  168 

LOBOUND  74 

LOCAL  76 

LOCAL-BODT-ITEM  224 

LOCAL-CAN-BE  226 

LOCAL-DECL 226 

LOCAL-ID  160 

LOG  76 

LOGIC  77 

L0G2  78 

LOGICAL  70 

LOGICAL-LITERAL  160 

LOGICAL-TTPE  227 

MAP  80 

MAP-DECL  228 

MAP-ID  161 

MAP-TTPE  220 

MINUS  81 

MINUS -OPERATOR  162 

MOD  82 

MODULO -OPERATOR  163 

MULTIPLICATION-LIKE-OPERATIONS  .164 

MULTIPLY -OPERATOR  83 

NESTED-ID-LIST  230 


NOT  84 

NOT-EQUAL-OPERATOR  86 

NOT-OPERATOR  166 

NULL 86 

NULLIFY  87 

NUMBER  88 

NUMBER-TYPE  231 

ODD  80 

OF  00 


ID-CHAR(140)  ID-SIMPLE (162) 
LIKE-0PERAT0R(167) 
RELATIONAL-OPERATQR-EXTENDED ( 171 ) 

CARDINALITY-OPERATORClSO) 

AGGREGATE-TYPE (180)  LIST-TYPE (223) 
SET-TTPE(247) 

GENERAL- AGGREGATION (212)  LIST-TTPE (223) 
AGGREGATION-TYPEdSl) 

SIMPLE-FACTOR (240) 

BUILT- IN -FUNCTION-NAME ( 1 37) 

LOCAL-DECL (226) 

LOCAL-DECL (226) 

L0CAL-B0DT-ITEM(224) 

ACTION-BODY (178) 

INCREMENT-C0NTR0L(217) 

BUILT- IN-FDNCTION-NAME( 137) 

BUILT- IN-FUNCTION-NAME ( 1 37 ) 

BUILT- IN-FUNCTION-NAME (137) 
L0GICAL-TYPE(227) 

LITERAL(168) 

BASE-TYPE (186) 

MAP-DECL(228) 

BL0CK-MEMBER(187) 

MAP-DECL(228)  MAP-TYPE(220) 
AnRIBUTE-CAN-BE(188) 

PARAMETER-CAN-BE(232)  RESULT-CAN-BE(240) 
MINUS -OPERATOR (162)  SIGN(176) 
ADDITI0N-LIKE-0PEXATI0NS(134) 

MODULO - OPERATOR ( 163 ) 
MULTIPLICATION-LIKE-OPERATIONS ( 164 ) 
TERM(250) 

MULTIPLICATION-LIKE-OPERATIONS (164) 
ENUMERATION-TYPE (201 ) 

EXPORT-DIRECTIVE (205)  RDLE-DECL(243) 
SELECT-TYPE (246)  SUBTYPE -DECL (255) 

USES -DIRECTIVE (265) 

NOT-OPERATOR (165) 

RELATIONAL-OPERATOR ( 170) 

SIMPLE-FACTOR (240) 

SUPERTTPE-FACT0R(258) 

BUILT-IN-PR0CEDDRE-NAME(138) 

NUMBER- TYPE (231) 

BASE-TYPE (186)  TYPE -CAN -BE (260) 

BUILT- IN-FUNCTION-NAME (137) 
AGGREGATE-TYPE (180)  ARRAY -TYPE (182) 
CASE-STATEMENT (101) 

ENUMERATION-TYPE (201 ) 

GENERAL-AGGREGATION (212)  LIST-TTPE (223) 
SET-TTPE(247)  SUBTYPE-DECL(265) 
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SUPERTYPE -DECL ( 25e ) 


OPTIONAL  Cl 

oa-oPERATOR  ice 

OTHERWISE  02 

PARAMETER-CAN-BE  232 

PI  03 

PLUS  04 

PLUS -OPERATOR  167 

PRECISION-SPEC  233 

PROCEDURE  05 

PROCEDURE-CALL-STATEMENT  234 

PROCEDURE -DECL  235 

PROCEDURE- ID  168 

QUALIFICATION  236 

REAL  06 

REAL-DIVIDE- OPERATOR  07 

REAL-LITERAL  160 

REAL-TYPE  237 

RELATIONAL-OPERATOR 170 

REUTIONAL-OPERATOR-EITENDED  ...  171 

REPEAT  08 

REPEAT-CONTROL  238 

REPEAT-STATEMENT  230 

RESULT-CAN-BE  240 

RETURN  00 

RETURN -STATEMENT  241 

RETYPE  100 

RETYPE-DECL  242 

RIGHT-BRACKET  101 

RIGHT-CURL  102 

RIGHT-PAREN  103 


RULE  104  I 

RULE-DECL  243  I 

RULE-ID  173  I 

SCHEMA  105  I 


SCHm-DECL 


ARRAT-TYPE(182)  EIPLICIT-ATTRIBUTE(203) 
ADDITION-LIKE-OPERATIONS (134) 
SUPERTYPE-EIPRESSION (257) 
CASE-OTHERWISE(IOO) 

FORMAL-P ARAMETER ( 208 ) 

GENERAL-AGGREGATION (212) 

CONSTANT (140) 

PLDS-0PERAT0R(167)  SIGN(175) 
ADDITI0N-LIKE-0PE31ATI0NS(134) 

INTEGER-TYPE (220)  REAL-TYPE (237) 
STRING-TYPE (252) 

PR0CEDURE-DECL(235) 

STATEMENT (251) 

BLOCK-MEMBER (187) 
PROCEDURE-CALL-STATEMENT (234 ) 
PR0CEDURE-DECL(235) 

FUNCTION-CALL (210) 

REAL- TYPE (237) 

DIVIDE-OPERATOR (143) 

LITERAL(158) 

BASE -TYPE (186) 

RELATIONAL-OPERATOR-EITENDED ( 171) 

INTERVAL (221) 

EXPRESSION (206) 

REPEAT-STATEMENT (230)  ' 

REPEAT-STATEMENT (230) 

STATEMENT (251) 

DERIVED-ATTRIBUTE(105)  FDNCTI0N-DECL(211) 
RETURN - STATEMENT (24 1 ) 

STATEMENT (251) 

RETYPE-DECL(242) 

MAP-DECL(228) 

INDEX-SPEC (21 8)  LIMIT-SPEC (222) 
SET-C0NSTRDCT(246)  SUBSCRIPT (253) 

INTERVAL (221) 

ACTUAL-PARAMETER-LIST (170) 

ASSUME-D IRECTIVE ( 1 84 ) 
FORMAL-PARAMETER-LIST (200) 

NESTED -ID -LIST (230)  PRECISI0N-SPEC(233) 
RETURN - STATEMENT (24 1 ) 

SIMPLE-FACTOR (240)  SUPERTYPE -DECL (256) 
SUPERTYPE-FACTOR (258) 

RULE-DECL (243) 

BLOCK-MEMBER (187> 

RULE-DECL (243) 

SCHEMA -DECL (244) 


244  I BLOCK -MEMBER (187) 
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SCHDU-n)  174  I ASSnME-DIBECTIVE(184)  SCHEMA -DECLC 244) 

SELECT  IOC  I 6ELECT-TTPE(245) 

SELECT-TTPE 246  I TYPE -C AH -BE (260) 

SEMICOLON  107  | ASSIGNMENT-STATD(ENT(183) 


ASS0ME-DIBECTIV1(184)  CASE -STATiMENTC 101) 
COMPOUND-STATEMENT ( 102) 
OEFINE-OIBECTIVECIOS} 

DERIVED-ATTEIBUTEC 106) 

DUMMY -STATEMENT ( 108 ) 

ENTITT-DEa(lOO)  ESCAPE-STATEMENT (202) 
EXPLICIT- ATTRIBUTE ( 203 ) 

EXPORT-DIRECTIVE (206) 
FORMAL-PARAMETER-LIST (200) 
FUNCTI0N-DECL(211)  INCLUDE-DIRECTIVE(216) 
L0CAL-B0DY-ITEM(224) 

L0CAL-DECL(226)  MAP-DECL(228) 
PROCEDURE-CALL- STATEMENT (234 ) 
PR0CEDURE-DECL(236) 

REPEAT-STATEMENT (230) 

RETURN-STATEMENT (241)  RETYPE -DEa (242) 
RULE-DECL(243)  SCHEMA -DECL( 244) 
SKIP-STATiMENT(260)  TYPE-DECL(261) 

TYPE- ITEM (262)  UNIQUE -RULE (263) 
USES-DIRECTIVE(26S)  ¥HERE-RULE(266) 


SET  108  I CENERAL-ACGREGATI0N(212)  SET-TTPE(247) 

SET-CONSTRUCT  246  | SIMPLE-FACTOR(240) 

SET-TYPE  247  | ACGREGATI0N-TYPE(181) 

SIGN  176  I REAL-LITERAL (160)  SIMPLE-EXPRESSION (248) 

SIMPLE-EXPRESSION  248  I EXPRESSION (206) 

SIMPLE-FACTOR  240  I FACTOR (207) 

SIN  100  I BUILT-IN-FUNCTI0N-NAME(137) 

SIZEOF  110  I BUILT-IN-FUNCTI0N-NAME(137) 

SKIP  Ill  I SKIP-STATEMENT (250) 

SKIP- STATEMENT  260  I STATEMENT (251) 

SORT  112  I BUILT- IN-FUNCTION-NAME (137) 

STATEMENT  251  I ACTI0N-B0DY(178)  CASE-ACTI0N(188) 


CASE-OTHERWISE (100) 

COMPOUND-STATEMENT ( 102) 
IF-STATEMENT(216)  REPEAT-STATEMENT (230) 
WITH-STATEMENT(268) 


STRING  113  I STRING-TYPE(262) 

STRING -LITERAL  176  I LITERAL(168)  DEFINE-DIRECTIVE(103) 

INaUDE-DIRECTIVE(216) 

STRING-TYPE  252  I BASE-TYPE(186) 

SUBSCRIPT  253  I ID-INDEXED(160)  QUALIFICATION (236) 

SUESUPER-DECL  254  I ENTITT-DECL(IOO)  MAP-DECL(228) 

SUBTYPE  114  I SUBTYPE-DECL(255) 

SUBTYPE-DECL  256  I SUBSUPER-DECL(254) 

SUPERTYPE  116  I SUPERTTPE-DECL(256) 
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BUPERTTPE-DECL  250  I SUBSUPER-DECL(264) 

SUPEXTTPE-EIPRESSION  267  I SUPERTTPE-DECL(260)  SUPEETTPE-FACTQR(258) 

SUPERTTPE-FiCTOR  258  I SUPERTYPE-EIPRESSI0N(267) 

TAIL-REMARK  177  I REMARK (172) 

TAN  116  I BUILT- IN-FUNCTION-NAMZ( 137) 

TERM 250  i SIMPL£-EXPR£SSI0N(248) 

THEN  117  I IF-STATEMENT(216) 

TO  118  I INCREMENT-C0NTR0L(217) 

TRUE  110  I C0NSTANT(140)  LOGICAL-LITERAL (160) 

TYPE  120  I TYPE-DECL(261) 

TTPE-CAN-BE  260  I TYPE- ITEM (262) 

TYPE-DECL  261  I BL0CK-MEMBER(187) 

TYPE-ITEM  262  I TYPE-DECL (261) 

TYPEOF  121  I BUILT-IN-rUNCTI0N-NAME(137) 

UNDERSCORE  122  I ID-CHAR(140) 

UNIQUE  123  I ACGREGATE-TYPE(180)  ARRAY-TYPE (182) 

LIST-TYPE (223)  UNIQUE-RULE(263) 

UNIQUE-RULE 263  I ENTITY-DEa(lOO)  MAP-DECL(228) 

UNKNOWN  124  I C0NSTANT(140)  LOGICAL-LITERAL (160) 

UNTIL  125  I UNTIL-C0NTR0L(264) 

UNTIL-CONTROL  264  I REPEAT -CONTROL (238) 

USES  126  I USES-DIRECTIVE(26S) 

USES-DIRECTIVE  265  I DIRECTIVE(107) 

VALUE  127  I BUILT-IN-FUNCTI0N-NAME(137) 

VAR  128  I F0RMAL-PARAMETER(208) 

VARYING  120  I STRING-TYPE(252) 

VIOUTION  130  I BUILT- IN-PROCEDURE-NAME (138) 

WHERE  131  I WHERE-RULE(266) 

WHERE-RULE  266  I ENTITY-DEa(lOO)  MAP-DECL(228) 

WHILE  132  I WHILE -CONTROL (267) 

WHILE-CONTROL  267  | REPEAT- CONTROL (238) 

WITH  133  I WITH-STATEMENT(268) 

WITH-STATEMENT  268  I STATEMENT (251) 

bf  RULE  DEFINITION 

1 ABS  • *ABS‘ 

2 ACOS  - ’ACOS*  . 

3 AGGREGATE  • ’AGGREGATE’  . 

4 AND  - ’AND’  . 

5 ARRAY  ■ ’ARRAY’  . 

6 AS  - ’AS’ 

7 ASIH  - ’ASIN'  . 

8 ASS  I CNT^NT- OPERATOR  - . 

0 ASSUME  • ’ASSUME’  . 

10  ATAN  • ’ATAN’  . 
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11  BEGIN  - 'BEGIN'  . 

12  BY  • 'BY*  . 

13  CASE  - 'CASE*  . 

14  COLON  • • : • . 

16  COMMA  « ’ . * . 

16  CONCATENATION -OPEEATOR  - ' | | * . 

17  COS  • 'COS*  . 

18  DEFINE  • 'DEFINE*  . 

10  DERIVE  • 'DERIVE*  . 

20  DIV  ■ 'DIV*  . 


21  DOT  - '.*  . 

22  DYNAMIC  • 'DYNAMIC*  . 

23  ELSE  - 'ELSE*  . 

24  END  • 'END*  . 

25  END-CASE  • 'END.CASE*  . 

26  END-ENTITY  - 'END .ENTITY*  . 

27  END-FUNCTION  ■ * END .FUNCTION*  . 

28  END-IF  ■ 'END.IF*  . 

20  END-LOCAL  • 'END .LOCAL*  . 

30  END-MAP  - 'END.MAP*  . 


31  END-PROCEDURE  - * END .PROCEDURE* 

32  END -REPEAT  • 'END .REPEAT*  . 

33  END-RULE  • * END .RULE’  . 

34  END-SCHEMA  - ’END.SCHEMA’  . 

35  END-TYPE  • ’END.TYPE*  . 

36  ENTITY  ■ ’ENTITY*  . 

37  ENUMERATION  ■ ’ENUMERATION*  . 

38  EQUAL  - *-*  . 

30  ESCAPE  - 'ESCAPE*  . 

40  EVERYTHING  - 'EVERYTHING*  . 


41  EXCEPT  - 'EXCEPT*  . 

42  EXCLUSIVE-OR-OPERATOR  - *XOR*  . 

43  EXISTS  - 'EXISTS*  .. 

44  EXP  - *EXP*  . 

45  EXPONENTIATION-OPERATOR  • ’**’  . 

46  EXPORT  - ’EXPORT*  . 

47  EXTERNAL  - ’EXTERNAL*  . 

48  FALSE  - ’FALSE*  . 


40  FOR  ■ 'FOR'  . 

BO  FORMAT  - ’FORMAT*  . 


61  FROM  • 'FROM*  . 

62  FUNCTION  • ’FUNCTION*  . 

63  GENERIC  ■ ’GENERIC’  . 

64  GREATER-EQDAL-OPERATOR  - ’> 
66  GREATER -THAN -OPERATOR  - ’>’ 

66  HIBOUND  ■ ’HIBOUNU’  . 

67  IF  - ’IF’  . 

68  IN  ■ ’IN’  . 

60  INCLUDE  • ’INCLUDE*  . 

60  INCLUSIVE- OR- OPERATOR  ■ ’OR 


61  INFINITY  - . 

62  INSERT  • ’INSERT*  . 

63  INSTANCE-EQUAL-OPERATQR  - * 

64  INSTANCE-NOTEQUAL-OPERATOR 

65  INTEGER  - ’INTEGER*  . 

66  INTERNAL  • ’INTERNAL*  . 

67  LEFT-BRACKET  • ’[’  . 

68  LEFT-CURL  - *{*  . 

60  LEFT-PAREN  • ’ ( * . 

70  LESS -EQUAL -OPERATOR  - *<-* 


71  LESS -THAN -OPERATOR  - *<*  . 

72  LIKE  - ’LIKE*  . 

73  LIST  - ’LIST*  . 

74  LOBOUND  • ’LOBOUND*  . 

75  LOCAL  - ’LOCAL*  . 

76  LOG  - ’LOG* 

77  LOGIC  - ’LOGIC*  . 

78  L0G2  ■ *L0G2*  . 

70  LOGICAL  - ’LOGICAL*  . 

80  MAP  ■ ’MAP’ 


81  MINUS  ■ *-•  . 

82  MOD  » 'MOD*  . 

83  MULTIPLT-OPERATOR  - *•*  . 

84  NOT  - ’NOT*  . 

85  NOT-EQUAL-OPERATOR  • *<>*  . 
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86  NULL  - ‘NULL’  . 

87  NULLIFT  - * NULLIFY ' . 

88  NUMBER  - ’NUMBER’  . 

80  ODD  - ’ODD’  . 

©0  OF  - ’OF’  . 


91  OPTIONAL  - ’OPTIONAL’  . 

02  OTHERWISE  ■ ’OTHERWISE’  . 

03  PI  ■ ’PI’  . 

94  PLUS  ■ ’♦’  . 

05  PROCEDURE  - ’PROCEDURE’  . 

06  REAL  - ’REAL’  . 

07  REAL-DIVIDE-OPERATQR  • ’/*  . 

08  REPEAT  - ’REPEAT’  . 

00  RETURN  - ’RETURN’  . 

100  RETYPE  - ’RETYPE’  . 


101  RIGHT-BRACKET  • . 

102  RIGHT-CURL  - . 

103  RIGHT-PAREN  - . 

104  RULE  • ’RULE’  . 

105  SCHEMA  - ’SCHEMA’  . 

106  SELECT  - ’SELECT’  . 

107  SEMICOLON  - ’ ; ’ . 

108  SET  • ’SET’  . 

109  SIN  - ’SIN’  . 

110  SIZEOF  - ’SIZEOF’  . 


111  SKIP  - ’SKIP’  . 

112  SQRT  - ’SORT’  . 

113  STRING  • ’STRING’  . 

114  SUBTYPE  • ’SUBTYPE’  . 

115  SUPERTYPE  • ’SUPERTYPE’  . 

116  TAN  - ’TAN’  . 

117  THEN  • ’THEN’  . 

118  TO  • ’TO’  . 

119  TRUE  - ’TRUE’  . 

120  TYPE  - ’TYPE’  . 


121  TYPEOF  - ’TYPEOF’  . 

122  UNDERSCORE  • . 
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123  UNIQUE  - 'UNIQUE'  . 

124  UNKNOWN  • 'UNKNOWN*  . 

126  UNTIL  • 'UNTIL'  . 

126  USES  • 'USES'  . 

127  VALUE  • 'VALUE'  . 

128  VAE  • 'VAR'  . 

120  VARTING  • * VARYING'  . 

130  VIOUTION  • 'VIOLATION'  . 


131  WHERE  - 'WHERE'  . 

132  WHILE  • 'WHILE'  . 

133  WITH  - 'WITH'  . 

134  ADDITION-LIKE-OPERATIONS  • PLUS-OPERATOR  I MINUS-OPERATOR 
I OR-OPERATOR  I CONCATENATION-OPERATOR  . 

135  AND-OPERATOR  - AND  . 

136  ATTRIBUTE-ID  • ID-SIMPLE  . 

137  BUILT- IN-FUNCTION-NAME  • ABS  I ACOS  I ASIN  I ATAN  I COS  I EXISTS 

I EXP  I FORMAT  I HIBOUND  I LOBOUND  I LOG  I LOGIO  I L0G2  I ODD 

I SIN  I SIZEOF  I SORT  I TAN  I TTPEOF  I VALUE  . 

138  BUILT- IN-PROCEDURE-NAME  - INSERT  I NULLIFY  I VIOUTION  . 

130  CARDINALITY-OPERATOR  - LIMIT-SPEC  . 

140  CONSTANT  - FALSE  I TRUE  I UNKNOWN  I PI  . 


141  DEFINED -TYPE- ID  • ID-SIMPLE  . 

142  DIGIT  - '0'  I '!'  I '2'  I '3'  I '4'  I '6'  I '6'  I '7'  1 '8'  I 'O'  . 

143  DIVIDE-OPERATOR  - INTEGER-DIVIDE-OPERATOR  I REAL-DIVIDE-OPERATOR  . 

144  EMBEDDED -REMARK  • '(*'  { \A  I \T  I \N  } '•)'  . 

145  ENTITY-ID  • ID-SIMPLE  . 

146  EQUAL-OPERATOR  - EQUAL  . 

147  FUNCTION-ID  • BUILT -IN -FUNCTION -NAME  I ID-SIMPLE  . 

148  ID  • ID-SIMPLE  I ID-QUALIFIED  . 

140  ID-CHAR  • LETTER  I DIGIT  I UNDERSCORE  . 

150  ID- INDEXED  - ID  { SUBSCRIPT  } . 


151  ID-QUALIFIED  - ID-INDEXED  { DOT  ID-INDEXED  } . 

162  ID-SIMPLE  • LETTER  { ID-CHAR  } . 

153  IN-OPERATOR  - IN  . 

154  INTEGER-DIVIDE-OPERATOR  - DIV  . 

155  INTEGER-LITERAL  - DIGIT  { DIGIT  } . 

156  LETTER  • 'A'  I 'B*  I 'C'  I 'D'  I 'E'  I 'F'  I 'G'  I 'H'  I '!'  I 'J' 
1 'K'  I 'L'  1 'M'  I 'N'  I '0*  I 'P'  I 'Q'  I 'R'  I 'S'  I 'T'  I 'U' 

1 'V  I 'W'  I I 'Y'  I 'Z'  . 

157  LIKE-OPERATOR  « LIKE  . 
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158  LITERAL  ■ IKTEGEE-LITERAL  I REIL-LITERAL  I iTRIHG'LITERAL 
I LOGICAL-LITEKAL  I CONSTANT  . 

160  LOCAL-ID  - ID  . 

160  LOGICAL-LITERAL  - TRUE  I FALSE  I UNKNOWN  . 


161  MAP-ID  - ID-SIMPLE  . 

162  MINUS-OPERATOR  - MINUS  . 

163  MODULO-OPERATOR  ■ MOD  . 

164  MULTIPLICATION-LIKE-OPERATIONS  - MULTIPLY- OPERATOR  I DIVIDE -OPERATOR 
I MODULO-OPERATOR  I AND-OPERATOR  . 

165  KOT-OPERATOR  - NOT  . 

166  OR-OPERATOR  - INCLUSIVE-OR-OPERATOR  I EXCLUSIVE-OR-OPERATQR  . 

167  PLUS-OPERATOR  - PLUS  . 

168  PROCEDURE- ID  • BUILT-IN-PROCEDURE-NAME  I ID-SIMPLE  . 

160  REAL-LITERAL  • INTEGER-LITERAL  DOT  [ INTEGER-LITERAL  ] [ ’E’  [ SIGN  3 
INTEGES-LITERAL  ] . 

170  RELATIONAL-OPmTOR  ■ LESS -THAN -OPERATOR  I GREATER-THAN-OPERATOR 
I EQUAL-OPERATOR  I LESS-EQUAL-OPERATOR  I GREATER-EQUAL-OPERATOR 

I HOT-EQUAL-OPERATOR  I INSTANCE-EQUAL-OPERATOR 
I INSTANCE-NOTEQUAL-OPERATOR  . 

171  RELATIONAL-OPERATOR-EITENDED  • RELATIONAL-OPERATOR  I IN-OPERATOR 
1 LIKE- OPERATOR  I CARDINALITY -OPERATOR  . 

172  REMARK  - EMBEDDED -REMARK  i TAIL-REMARK  . 

173  RULE-ID  ■ ID-SIMPLE  . 

174  SCHEMA-ID  • ID-SIMPLE  . 

175  SIGN  - PLUS  I MINUS  . 

176  STRING-LITERAL  - \Q  { \A  I ( \Q  \Q  ) > \Q  . 

177  TAIL-RDORK  • ' — ’ { \A  I \T  } \N  . 

178  ACTION-BODY  • { BLOCK-MEMBER  I LOCAL-DECL  } ( STATEMENT  } . 

170  ACTUAL-PARAMETER-LIST  - LEFT-PAREN  EXPRESSION  { COMMA  EXPRESSION  } 
RIGHT-PAREN  . 

180  AGGREGATE-TYPE  - AGGREGATE  LIMIT-SPEC  OF  [ UNIQUE  ] ATTRIBUTE-CAN-BE  . 


181  AGGREGATION-TYPE  • AGGREGATE-TYPE  I ARRAY-TYPE  I UST-TYPE  I SET-TYPE  . 

182  ARRAY-TYPE  • ARRAY  INDEX-SPEC  OF  [ OPTIONAL  ] [ UNIQUE  ] ATTRIBUTE-CAN-BE 

183  ASSIGNMENT-STATEMENT  • ID  ASSIGNMENT- OPERATOR  EXPRESSION  SEMICOLON  . 

184  ASSUME-DIRECTIVE  • ASSUME  LEFT-PAREN  SCHEMA-ID  { COMMA  SCmiA-ID  } 
RIGHT-PAREN  SEMICOLON  . 

185  ATTRIBUTE-CAN-BE  - AGGREGATION-TYPE  I BASE-TYPE  I DEFINED-TYPE 
I ENTITY-TYPE  I MAP-TYPE  . 

186  BASE-TYPE  ■ INTEGER-TYPE  I LOGICAL-TYPE  I NUMBER-TYPE  I REAL-TYPE 
I STRING -TYPE  . 

187  BLOCK-MEMBER  • ENTITY-DECL  I MAP-DECL  I FUNCTION-DECL  I PROCEDURE-DECL 
I RULE-DECL  I SCHEMA-DECL  I TTPE-DEa  I DIRECTIVE  . 
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188  CASE-ACTION  - EXPRESSION  { COMMA  EXPRESSION  > COLON  STATEMENT  . 
180  CASE-BLOCK  ■ CASE-ACTION  { CASE-ACTION  } [ CASE -OTHERWISE  ] . 
100  CASE-OTHERWISE  • OTHERWISE  COLON  STATEMENT  . 


101  CASE -STATEMENT  - CASE  EXPRESSION  OF  CASE-BLOCK  END-CASE  SEMICOLON  . 

102  COMPOUND-STATEMENT  • BEGIN  < STATEMENT  > END  SEMICOLON  . 

103  DEFINE-DIRECTIVE  ■ DEFINE  DEFINED-TTPE-ID  STRING-UTERAL  SEMICOLON  . 

104  DEFINED-TTPE  ■ DEFINED-TTPE-ID  . 

106  DERIVED-ATTRIBUTE  - ATTRIBUTE- ID  COLON  RESULT-CAN-BE  INITIALIZER 
SEMICOLON  . 

106  DERIVED- ATTRIBUTE-DEa  ■ DERIVE  DERIVED -ATTRIBUTE  { DERIVED -ATTRIBUTE  > 

107  DIRECTIVE  - ASSUME-DIRECTIVE  I DEFINE-DIRECTIVE  I EXPORT -DIRECTIVE 
I INCLUDE-DIRECTIVE  I USES -DIRECTIVE  . 

108  DUMMY -STATEMENT  - SEMICOLON  . 

100  ENTITY-DECL  • ENTITY  ENTITY-ID  [ SUBSUP ER-DECL  ] SEMICOLON 

[ EXPLICIT-ATTRIBUTE-DECL  ] [ DERIVED -ATTRIBUTE-DECL  ] [ UNIQUE-RULE  ] 

[ WHERE-RULE  ] END-ENTITY  SEMICOLON  . 

200  ENTITY-TYPE  - ENTITY-ID  . 


201  ENUMERATION -TYPE  • ENUMERATION  OF  NESTED- ID-LIST  . 

202  ESCAPE- STATEMENT  ■ ESCAPE  SEMICOLON  . 

203  EXPLICIT-ATTRIBUTE  • ID-LIST  COLON  [ OPTIONAL  ] [ EXTERNAL  I INTERNAL 
I DYNAMIC  ] ATTRIBUTE-CAN-BE  SEMICOLON  . 

204  EXPLICIT-ATTRIBUTE-DECL  - EXPLICIT-ATTRIBUTE  { EXPLICIT-ATTRIBUTE  } . 
206  EXPORT-DIRECTIVE  - EXPORT  ( NESTED- ID-LIST  I EVERYTHING  I EVERYTHING 

EXCEPT  NESTED-ID-LIST  ) SEMICOLON  . 

206  EXPRESSION  - SIMPLE-EXPRESSION  { REUTIONAL-OPERATOR-EXTENDED 
SIMPLE- EXPRESSION  } . 

207  FACTOR  • SIMPLE-FACTOR  [ EXPONENTIATION-OPERATOR  SIMPLE-FACTOR  ] . 

208  FORMAL-PARAMETER  ■ [ VAR  ] ID-LIST  COLON  PARAMETER- CAN -BE  . 

200  FORMAL-PARAMETER-LIST  - LEFT-PAREN  FORMAL -PARAMETER  { SEMICOLON 

FORMAL- PARAMETER  } RIGHT-PAREN  . 

210  FUNCTION-CALL  - FUNCTION-ID  [ ACTUAL-PARAMETER-LIST  ] { QUALIFICATION  > 

211  FUNCTION-DECL  - FUNCTION  FUNCTION-ID  [ FORMAL-PARAMETER-LIST  ] COLON 
RESULT-CAN-BE  SEMICOLON  ACTION-BODY  END-FUNCTION  SEMICOLON  . 

212  GENERAL- AGGREGATION  - ( AGGREGATE  I ARRAY  I LIST  I SET  ) OF 
PARAMETER-CAN-BE  . 

213  GENERIC-TYPE  - GENERIC  . 

214  ID-LIST  • ID-SIMPLE  { COMMA  ID-SIMPLE  } . 

216  IF-STATEMENT  - IF  EXPRESSION  THEN  STATEMENT  { STATEMENT  } [ ELSE 
STATEMENT  < STATEMENT  > ] END- IF  . 

216  INCLUDE-DIRECTIVE  « INCLUDE  STRING -LITERAL  SEMICOLON  . 

217  INCREMENT-CONTROL  - LOCAL-ID  ASSIGNMENT-OPERATOR  EXPRESSION  TO 
EXPRESSION  [ BY  EXPRESSION  ] . 

218  INDEX-SPEC  - LEFT-BRACKET  EXPRESSION  COLON  EXPRESSION  RIGHT-BRACKET  . 
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210  IMITIALIZEEl  • ASSIGNMEKT-OPERATOE  EXPRESSION  . 
220  INTEGER-TTPE  - INTEGER  [ PRECISION-SPEC  ] . 


221  INTERVAL  - LEFT-CURL  EXPRESSION  RELATIONAL-OPERATOR  EXPRESSION 
REUTIONAL-OPERATOR  EXPRESSION  RIGHT-CURL  . 

222  LIMIT-SPEC  - LEFT-BRACKET  EXPRESSION  COLON  ( EXPRESSION  I INFINITT  ) 
RIGHT-BRACKET  . 

223  LIST-TTPE  • LIST  LIMIT-SPEC  OF  [ UNIQUE  ] ATTRIBUTE -CAN -BE  . 

224  LOCAL-BODT-ITEM  - ID-LIST  COLON  LOCAL-CAN-BE  C INITIALIZER  ] SEMICOLON  . 

225  LOCAL-CAN-BE  • AGGREGATION-TTPE  I BASE-TTPE  I DEFINED-TTPE  I ENTITT-TTPE  . 

226  LOCAL-DECL  • LOCAL  < LOCAL-BODT-ITEM  } END-LOCAL  SEMICOLON  . 

227  LOGICAL-TTPE  - LOGICAL  . 

228  MAP-DECL  - MAP  MAP-ID  FROM  ENTITT-ID  [ SUBSUPER-DECL  ] SEMICOLON 
{ RETTPE-DECL  } [ UNIQUE-RULE  ] [VHERE-RULE  ] END-MAP  SEMICOLON  . 

220  MAP-TTPE  - MAP- ID  . 

230  NESTED- ID-LIST  ■ LEFT-PAREN  ID-LIST  RIGHT-PAREN  . 


231  NUMBER-TTPE  - NUMBER  . 

232  PARAMETER-CAN-BE  - GENERIC-TTPE  I GENERAL-AGGREGATION  I BASE-TTPE 
I DEFINED-TTPE  I ENTITT-TTPE  I MAP-TTPE  . 

233  PRECISION-SPEC  • LEFT-PAREN  EXPRESSION  RIGHT-PAREN  . 

234  PROCEDURE-CALL-STATEMENT  • PROCEDURE-ID  [ ACTUAL-PARAMETER-LIST  ] 
SEMICOLON  . 

236  PROCEDURE-DECL  - PROCEDURE  PROCEDURE-ID  [ FORMAL-PARAMETER-LIST  ] 
SEMICOLON  ACTION-BODT  END-PROCEDURE  SEMICOLON  . 

236  QUALIFICATION  - { SUBSCRIPT  > [ DOT  ID  ] . 

237  REAL-TTPE  - REAL  [ PRECIS I ON- SPEC  ] . 

238  REPEAT- CONTROL  - INCREMENT-CONTROL  I WHILE-CONTROL  I UNTIL-CONTROL  . 

239  REPEAT-STATEMENT  ■ REPEAT  < REPEAT-CONTROL  > SEMICOLON  { STATEMENT  } 
END-REPEAT  SEMICOLON  . 

240  RESULT-CAN-BE  - BASE-TTPE  I DEFINED-TTPE  I ENTITT-TTPE  I MAP-TTPE  I 
GENERIC-TTPE  . 

241  RETURN-STATEMENT  • RETURN  [ LEFT-PAREN  EXPRESSION  RIGHT-PAREN  ] SEMICOLON 

242  RETTPE-DECL  - ID-LIST  COLON  RETTPE  AS  ATTRIBUTE-CAN-BE  SEMICOLON 

243  RULE-DECL  - RULE  RULE-ID  FOR  NESTED-ID-LIST  SEMICOLON  ACTION-BODT 
END-RULE  SEMICOLON  . 

244  SCHEMA-DECL  • SCHEMA  SCHEMA-ID  SEMICOLON  { BLOCK-MEMBER  } END-SCHEMA 
SEMICOLON  . 

246  SELECT-TTPE  ■ SELECT  NESTED-ID-LIST  . 

246  SET-CONSTRUCT  • LEFT-BRACKET  [ EXPRESSION  < COMMA  EXPRESSION  > ] 
RIGHT-BRACKET  . 

247  SET-TTPE  - SET  [ LIMIT-SPEC  ] OF  ATTRIBUTE-CAN-BE  . 

248  SIMPLE-EXPRESSION  ■ [ SIGN  } TERM  { ADDITION-LIKE-OPERATIONS  TERM  } . 

240  SIMPLE-FACTOR  • LITERAL  I FUNCTION-CALL  I ID  I SET-CONSTRUCT  I 
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LEFT-Plfi£N  EXPRESSION  RIGHT-PiREN  I INTERVAL  I HOT-OPERATOR  SIMPLE-FACTOR 

260  SKIP -STATEMENT  ■ SKIP  SEMICOLON  . 

261  STATEMENT  ■ ASSIGNMENT-STATDOT  I CASE -STATEMENT  I COMPOUND -STATEMENT 
I DUMMY -STATEMENT  I ESCAPE-STATEMENT  I IF-STATEMENT 

I PROCEDURE-CALL-STATEMENT  I REPEAT -STATEMENT  I RETURN -STATEMENT 
I SKIP- STATEMENT  I WITH- STATEMENT  . 

262  STRING-TYPE  - STRING  [ PRECISION-SPEC  ] [ VARYING  ] . 

263  SUBSCRIPT  ■ LEFT-BRACKET  EXPRESSION  RIGHT-BRACKET  . 

264  SUBSUPER-DECL  • SUBTYPE-DECL  [ SUPERTYPE-DECL  ] 1 SUPERTYPE-DECL 
[ SUBTYPE-DECL  ] . 

266  SUBTYPE-DECL  ■ SUBTYPE  OF  NESTED -ID -LIST  . 

266  SUPERTYPE-DECL  • SUPERTYPE  OF  LEFT-PAREN  SUPERTYPE- EXPRESSION  RICHT-PAREN 

267  SUPERTYPE-EXPRESSION  - SUPERTYPE-FACTOR  { ( AND-OPERATOR  I OR-OPERATOR  ) 
SUPERTYPE- FACTOR  } . 

268  SUPERTYPE-FACTOR  • ID-SIMPLE  I NULL  I LEFT-PAREN  SUPERTYPE- EXPRESS I ON 
RIGHT-PAREN  . 

269  TERM  - FACTOR  { MULTIPLICATION-LIKE-OPERATIONS  FACTOR  > . 

260  TYPE-CAN-BE  - AGGREGATION -TYPE  I BASE-TYPE  I DEFINED-TYPE 
I ENUMERATION -TYPE  I NUMBER-TYPE  I SELECT-TYPE  . 

261  TYPE-DECL  - TYPE  TYPE- ITEM  { TYPE- ITEM  } END-TYPE  SEMICOLON  . 

262  TYPE-ITEM  - DEFINED -TYPE -ID  EQUAL  TYPE-CAN-BE  SEMICOLON  . 

263  UNIQUE-RULE  - UNIQUE  { ID-LIST  SEMICOLON  > . 

264  UNTIL-CONTROL  - UNTIL  EXPRESSION  . 

265  USES-DIRECTIVE  - USES  NESTED- ID -LI ST  SEMICOLON  . 

266  WHERE-RULE  - WHERE  { EXPRESSION  SEMICOLON  } . 

267  WHILE-CONTROL  - WHILE  EXPRESSION  . 

268  WITH- STATEMENT  - WITH  ID  STATEMENT  . 
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A. 13.3  £XPR£SS  Glossary 

Attribute  Aa  esMntial  property,  trait,  quality,  or  characteristic  (of  an  entity). 

BNT  Baucus>Nauer  Form.  A method  of  defining  the  morphology  of  a grammar. 
Gsnstraint  Same  as  rule. 

Data  The  repreMntation  forms  of  information  dealt  with  by  information  processing  sys* 
terns  and  users  thereof. 

Data  Base  Also  database.  See  Information  Base. 

Entity  An  information  unit  that  has  a uniform  meaning  and  behavior  within  a UoD. 

Fact  A fact  is  any  assertion  that  can  be  proved  (or  is  said)  to  be  true  for  some  UoD. 

Grammar  The  system  of  rules  that  governs  the  use  of  a language;  the  morphology  and 
semantics  of  a language. 

ICAM  Integrated  Computer  Aided  Manufacturing.  A project  of  the  United  States  Air 
Force. 

IGES  Initial  Graphic  Exchange  Specification. 

Information  Any  kind  of  knowledge  about  things,  facts,  concepts,  etc.  that  is  exchange- 
able  among  users.  Data  that  has  meaning. 

Information  Base  A consistent  collection  of  data  that  can  be  interpreted  and  operated 
on  by  the  information  system. 

Information  System  The  system  of  elements  including  the  schema,  information  base, 
hardware  devices,  and  the  user  that  forms  a predictable  mechanism  for  keeping  and 
manipulating  information. 

PDDI  Product  Data  Definition  Interface. 

PDE^  Product  Data  Exchange  Specification. 

Rule  A procedure  that  enforces  a fact. 

Schema  A consistent  collection  of  statements  expressing  the  necessary  propositions  that 
hold  for  some  UoD.  A description  of  a UoD. 

STEP  STandard  for  the  Exchange  of  Product  data. 

Token  An  element  (word)  of  a grammar,  which  can  be  distinguished  from  all  other  tokens. 

Type  A particular  representation  form  of  data  such  as  an  mteger  or  a character  string. 

Universe  of  Discourse  (UoD)  A Universe  of  Discourse  is  an  area  of  interest  that  is  of 
importance  to  an  individual  or  a group  of  individuals. 

User  Anybody  or  anything  that  issues  messages  to  the  information  system  and  receives 
messages  in  return. 
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A. 13. 3 Case  Study  One 

This  case  study  deals  with  rooms,  doors,  and  wharehousing  of  doors. 
A door  is  either  an  interior  door  or  an  exterior  door. 


SCHEMA  DOORS: 

ENTITT  DOOR  SUPERTYPE  OF  (INTERIOR.DOOR  lOR  EXTERIOR.DOOR) ; 
END.ENTITT; 

ENTITY  INTERIOR.DOOR  SUBTYPE  OF  (DOOR); 

END.ENTITY; 

ENTITY  EITERIOR.DOOR  SUBTYPE  OF  (DOOR): 

END.ENTITY: 

ENTITY  ROOM; 

END.ENTITY: 

SCHEMA  WHAREHOUSING; 

END.SCHEMA: 

SCHEMA  BUILDING.DESIGN; 

END.SCHEMA: 

END.SCHEMA: 
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CHAPTER  1 - INTRODUCTION 


1.0  INTRODUCTION 

The  Standard  for  the  Exchange  of  Product  Data  (STEP)  is  a neutral  exchange 
medium  capable  of  completely  representing  product  definition  data.  It  has  been 
designed  to  meet  both  present  and  future  requirements  for  exchanging  such  data 
between  dissimilar  CAD/CAM/CAE/C IM  Systems. 


1.1  DOCUMENT  ORGANIZATION 

This  document  specifies  the  STEP  file  structure  format  and  the  initial  STEP 
entity  set.  The  STEP  File  Structure  document  consists  of  seven  chapters. 


CHAPTER  1;  INTRODUCTION  - This  section  identifies  the  purpose  of  this  document. 

CHAPTER  2:  EXCHANGE  FORMAT  OVERVIEW  - This  section  provides  a high  level 

overview  of  the  STEP  file  structure. 

CHAPTER  3:  FORMAL  DEFINITIONS  - This  section  presents  a formal  description  of 

the  exact  syntax  of  the  STEP  file  structure. 

CHAPTER  4:  TOKENS  This  section  presents  an  informal  description  of  the 
parsing  tokens  as  they  should  be  recognized  by  STEP  processors. 

CHAPTER  5:  STRUCTURED  DATA  TYPES  - This  section  presents  an  informal 

description  of  the  Structured  Data  Types. 

CHAPTER  6;  HEADER  SECTION  - This  section  presents  an  informal  description  of 
the  HEADER  Section. 

CHAPTER  7:  DATA  SECTION  - This  section  presents  an  informal  description  of  the 
DATA  Section. 


Appendices  have  been  included  to  provide  additional  information  and  relevant 
exampl es . 
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CHAPTER  2 - EXCHANGE  FORMAT  OVERVIEW 


2.0  . EXCHANGE  FORMAT  OVERVIEW 

2.1  THEORETICAL  BASIS 

The  STEP  file  structure  is  language-based  and  is  described  by  an  unambiguous, 
context-free  grammar  to  facilitate  parsing  by  software.  The  grammar  is 
expressed  in  Wirth  Syntax  Notation  and  is  included  in  Chapter  3.0.  The 
majority  of  this  document  is  devoted  to  the  logical  and  syntactical  description 
of  a STEP  exchange  file.  See  Appendix  D for  detailed  descriptions  of  the 
format  of  the  file  on  various  exchange  media. 


2.2  GENERAL  STRUCTURE 
2.2.1  File  Format 

The  STEP  exchange  file  is  a sequential  file.  The  information  contained  within 
the  file  is  in  free  format.  There  is  no  column-dependent  information. 


2.2.2  Organization 

The  STEP  exchange  file  is  organized  in  a modular  manner.  The  file  consists  of 
several  sections.  These  sections  consist  of  one  or  many  entities.  An  entity 
consists  of  attributes.  These  file  components  are  defined  below. 


Sections  A section  is  a collection  of  data  of  the  same  functional 
category  of  information. 


Entity  An  entity  is  a collection  of  logically  associated  data. 


Attribute  An  attribute  is  a (data)  fact  about  an  entity.  It  is 

conceptually  atomic  (i.e.,  it  represents  a single  fact) 
although  it  may  be  arbitrarily  complex  in  structure.  An 
entity  is  defined  or  described  by  its  attributes. 


2.2.3  High  Level  File  Syntax 

The  STEP  file  is  begun  by  ''STEP;''  and  is  terminated  by  "ENDSTEP;".  Following 
the  "STEP;",  the  HEADER  and  DATA  sections  will  be  added.  These  sections  are 
described  in  subsections  2.3.1  and  2.3.2  of  this  document. 

Additional  sections  may  be  added  to  the  STEP  file  structure  in  the  future  in 
response  to  technological  advances  or  industry  requirements.  Therefore,  in 
order  to  preserve  future  compatibility,  postprocessors  should  be  prepared  to 
encounter  and  ignore  any  information  found  before,  between,  or  following  file 
sections. 
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2.3  SECTIONS  - FUNCTIONAL  DESCRIPTIONS 

Collections  of  data  serving  similar  functions  in  the  exchange  are  grouped  into 
sections.  There  will  be  two  sections  in  the  STEP  file  structure:  the  HEADER 
section  and  the  DATA  section.  Each  section  begins  with  a keyword  and  each 
section  keyword  is  followed  by  a semicolon  The  keywords  for  the  two 
sections  are  listed  below. 


Section 


Keyword 


HEADER 

DATA 


HEADER 

DATA 


2.3,1  HEADER  Section 

The  HEADER  section  provides  information  such  as  author  and  creation  date,  which 
is  applicable  to  the  entire  exchange  format  file.  The  section  is  begun  by 
"HEADER;"  and  is  terminated  by  "ENDSEC;".  This  section  must  appear  exactly 
once  in  the  file  and  must  be  first  in  the  file.  For  more  information 
concerning  the  HEADER  section,  refer  to  Chapter  6.0  of  this  document. 


2.3.2  DATA  Section 

The  DATA  section  is  used  to  define  the  product  data  to  be  transferred.  It  is  a 
collection  of  occurrences  of  the  standard  types  defined  in  the  Conceptual 
Schema.  The  DATA  section  is  begun  by  "DATA;"  and  is  followed  by  DATA  section 
entities.  The  DATA  section  is  terminated  by  "ENDSEC;".  This  section  must 
appear  exactly  once  in  the  file.  For  more  information  concerning  the  DATA 
section,  refer  to  Chapter  7.0  of  this  document. 
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CHAPTER  3 - FORMAL  DEFINITIONS 


3.0  FORMAL  DEFINITIONS 

3.1  FORMAL  NOTATION 

The  STEP  exchange  format  file  may  be  considered  as  a continuous  stream  of 
characters  from  the  basic  alphabet.  These  can  be  collected  into  recognizable 
strings  of  characters  called  tokens. 

The  neutral  file  can  therefore  be  considered  as  a sequence  of  tokens.  The 
tokens  can  be  formally  defined  by  a regular  set  R(G)  over  the  graphical 

alphabet  G.  STEP  tokens  are  discussed  in  detail  in  Chapter  3.3. 

3.1.1  WSN  NOTATIONAL  CONVENTIONS 

The  syntax  of  the  STEP  exchange  file  is  defined  in  Wirth  Syntax  Notation 

(WSN).  WSN  was  first  described  in  a letter  by  Niklaus  Wirth,  which  was 
published  in  Communications  of  the  ACM,  20:11  (Nov  77),  822-823.  The 
additional  notational  conventions  are  given  below.  Table  3-1  presents  WSN 
defined  in  itself. 

1.  A string  in  uppercase  (capital  letters)  is  an  element  of  the  language;  the 
string  is  the  name  of  the  element.  In  syntax  diagrams,  this  corresponds  to 
anything  in  a box  with  square  corners.  (For  convenience,  lowercase  is  used 
for  undefined  identifiers  and  commentary.) 

2.  Any  string  enclosed  in  double  quotation  marks  ( " ) is  literally  what  is 

contained  within  the  quotation  marks.  In  syntax  diagrams,  this  corresponds 
to  anything  in  a box  with  curved  corners.  The  one  exception  to  this  rule 
occurs  when  one  wishes  to  specify  a double  quotation  mark  within  a 
literal.  In  order  to  accomplish  this,  the  double  quotation  mark  is 

immediately  repeated  one  time. 


is  interpreted  as  " ) 


m 


3.  The  equals  sign  ( • ) indicates  a production.  The  element  on  the  left  is 
defined  to  be  the  combination  of  the  elements  on  the  right.  Any  spaces 
appearing  between  the  elements  of  a production  are  meaningless  unless  they 
appear  within  a quoted  literal.  A production  is  terminated  by  a period 


( . ). 
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4.  The  semantics  of  the  enclosing  braces  are  defined  below. 


CURLY  BRACKETS 
SQUARE  BRACKETS 
VERTICAL  BAR 
PARENTHESIS 


"{)"  indicates  zero  or  more  repetitions 
"[]"  indicate  optional  parameters 
"I"  indicates  the  logical  OR 

"{"  and  ")"  indicate  priority  operations.  In 
particular,  when  they  enclose  elements  separated  by 
vertical  bars,  one  of  the  elements  is  to  be  chosen  in 
conjunction  with  any  other  operation. 

e.g.  A(B1C|D)  » AB|AC|AD 


Table  3-1  Wirth  Syntax  Notation  (WSNl 


SYNTAX 

m 

{ PRODUCTION  ). 

PRODUCTION 

m 

IDENTIFIER  EXPRESSION 

EXPRESSION 

M 

TERM  ( "1"  TERM  }. 

TERM 

M 

FACTOR  { FACTOR  }. 

FACJOR 

9 

IDENTIFIER 

LITERAL 

'•{”  EXPRESSION 

IDENTIFIER 

9 

letter  { letter  }. 

LITERAL 

9 

" character  { character  } 
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3.2  ALPHABET  DEFINITION 

The  alphabet  of  the  STEP  neutral  file  language  is  defined  as  a set  of  bytes 
with  integer  values  ranging  from  32  to  126.  The  standard  "ISO  5937/1  19a3(E)" 
defines  the  correspondence  of  the  neutral  file  alphabet  into  graphical 
representation  on  paper  and  terminals.  This  function  is  limited  by  the 
capability  of  the  hardware  to  accommodate  such  transformation  from  code  to 
graphics. 

The  correspondence  of  the  neutral  file  alphabet  into  graphical  representation 
is  presented  in  Appendix  B - The  Graphical  Alphabet  within  this  document.  To 
define  the  syntax  of  the  neutral  file  language,  only  the  graphical 
representation  is  used,  where  G(k)  denotes  the  graphical  representation  of  the 
byte  with  the  decimal  value  "k".  The  international  monetary  symbol  cannot  be 
printed  by  the  text  system  that  generates  this  document.  In  its  place,  a 
dollar  sign  will  appear. 


3.2.1  ALPHABET  SUBSETS 


Table  3-2  Alphabet  Subsets 


SPACE 

It  It 

1 , 

DIGIT 

"0" 

"1" 

"2" 

"3" 

••4» 

"5" 

”6" 

"7" 

"8" 

ngii 

LOWER  - "a" 

"b" 

II  ^ It 

■'d" 

iigii 

II  y tt 

"g" 

"h" 

It  ^ It 

"k" 

II  1 tl 

"m" 

"n" 

”o" 

"p" 

"q" 

1 pH 

II  ^ II 

"t" 

"u" 

"y" 

"w" 

"x" 

"y" 

It  2 » 

UPPER  - "A" 

"B" 

"C" 

"0" 

It  £ II 

II  p II 

"G" 

"H" 

M J tt 

"K" 

II  ^ II 

"M" 

"N" 

"0" 

It  p II 

„Q„ 

"R" 

"S" 

II  y II 

"U" 

"y  " 

"W" 

"X" 

II Y '* 

II  2 II 

II  II 

SPECIAL  - ■'!" 

II  II  II  II 

II  ^ II 

II  / It 

It  II 

"4" 

" + " I 

tl  If 

1 

II  II 

II  ^ II 

fi  j It 

II  ^ II 

II  j It 

tl  • 11 

II , II 

I 

II  II  j 

It  ^ II 

II  \ II 

"(3'' 

II  ^ II 

II  \^ii 

11  j M 

II  ^ II 

tl  1 II 

II  ^ II 

II  II 

II  A tl 

ALPHABET 

. SPACE  1 DIGIT  1 LOWER 

1 UPPER 

1 SPECIAL. 
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3.3  TOKENS  DEFINED  BY  REGULAR  EXPRESSIONS 

The  following  regular  expressions  in  Table  3-3  will  refer  to  those  regular 
expressions  defined  previously  in  Table  3-2  Alphabet  Subsets.  The  tokens  that 
are  intended  to  be  recognized  during  lexical  analysis  are  given  below  in  the 
TOKEN  definition.  Please  note  that  this  TOKEN  definition  has  been  supplied 
only  as  a convenience  to  the  reader,  it  will  not  be  referenced  by  the  WSN 
description  of  the  file. 

TOKEN  - DELIMITER  I RESERVED  WORD  I KEYWORD | INTEGER | REALISTRING  1 COMMENT 
ENTITY_IDENTIFIER| ENUMERATION! ENTITY 


Table  3-3  Token  Definition  (1  of  21 


COMMENT 

a 

"/*”  any_sequence_except_*_fol lowed_by^ 

DELIMITER 

a 

1 

"("  1 ")■'  1 1 1 "/"  1 1 "ENDSEC;" 

"ENDSTEP;". 

KEYWORD 

a 

UPPER{UPP£R1DIGIT)|  ‘'!‘'  UPP£R(UPPER1  DIGIT) . 

SIGN 

a 

11  ^ I M ^ II 

INTEGER 

a 

[ SIGN  ] DIGIT  { DIGIT  }. 

REAL 

a 

[ SIGN  ] DIGIT  { DIGIT  } " . " { DIGIT  } 

[ "E"  [ SIGN  ] DIGIT  { DIGIT  } ]. 

NON_Q_CHAR 

a 

any_character_from_the_al phabet_except_the_singl  e_ 
apostrophe. 

QUOTE.CHAR 

a 

II  ^ / M 

ESC.CHAR 

a 

"1:1:". 

ESC.ITEM 

a 

"IS06937"  1 "GREEK"  1 "KANJI"  | INTEGER. 

ESC_SEQ 

a 

"!:  [ ESC.ITEM  { ESC.ITEM  ) ] ":1". 

STRING 

a 

{ NON  Q CHAR  | QUOTE  CHAR  | ESC  CHAR  1 

ESC.SEQ 
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Table  3-3  Token  Definition  (2  of  2) 


£NTITY_NAME 

- DIGIT  [ DIGIT  [ DIGIT  [ DIGIT 

[ DIGIT  [ DIGIT 

- [ DIGIT  [ DIGIT  [ DIGIT  ] ] ] 

]]]]]. 

ENTITY.IDENTIFIER 

- "0"  ENTITY.NAME. 

ENTITY.REFERENCE 

» ENTITY_NAME. 

ENUMERATION 

- UPPER{UPPER|DIGIT} 
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3.4  WSN  OF  THE  STEP  FILE  STRUCTURE 

Table  3-4  identifies  the  WSN  for  the  syntax  of  a STEP  file.  This  WSN  does  not 
take  into  account  any  particular  conceptual  schema,  but  represents  the  physical 
structure  for  all  possible  conceptual  schemata. 

This  syntax  includes  the  tokens  defined  in  section  3.3  of  this  document  and 
corresponds  to  the  syntax  diagrams  in  Appendix  C of  this  document. 


Table  3-4  WSN  of  the  STEP  File  Structure 


EXCHANGE  FILE  - "STEP;" 

HEADER  SECTION  DATA  SECTION 
"ENDSTEP;". 

HEADER  SECTION  - "HEADER;FILE  IDENTIFICATION! " STRING  STRING 

STRING  STRING  STRING  STRING  STRING 

");FILE  OESCRIPTIONC  STRING  ");IMP  LEVEL(" 

STRING  ");"  HEADER JNTITY.LIST  "ENDSEC;". 

HEADER.ENTITY.LIST  - HEADER.ENTITY  j HEADER_ENTITY_LIST  HEADER.ENTITY . 

HEADER.ENTITY  » KEYWORD  "("  PARAMETER.LIST  ")" 

PARAMETER.LIST  « PARAMETER  1 PARAMETER.LIST  PARAMETER. 

PARAMETER  » INTEGER  | REAL  1 STRING  | ENTITY  REFERENCE 

1 ENUMERATION  1 LIST  1 EMBEDDED.ENTITY. 

LIST  - "("  ([INTEGER]!  [INTEGER]}  1[R£AL]{  [REAL]} 

|[STRING]{  [STRING]}  | [ENUMERATION] { 

[ENUMERATION]}  |[LIST](  [LIST]}  ) | [ENTITY]! 

[ENTITY]}  ")". 

DATA_SECTION  » "DATA;"  ENTITY.OCCUR.LIST  "ENDSEC;". 

ENTITY  OCCUR  LIST  - ENTITY  OCCURRENCE  | ENTITY  OCCUR  LIST 

ENTITY.OCCURRENCE. 

ENTITY.OCCURRENCE  - ENTITY.IDENTIFIER  EMBEDDED.ENTITY 

EMBEDDED  ENTITY  - [KEYWORD  ["  SCOPE" 

ENTITY  OCCUR  LIST  "ENDSCOPE" 

[ENTITY  EXPORT  LIST]]] 

"("  PARAMETER.LIST  ")". 

ENTITY.EXPORT.LIST  » ENTITY.REFERENCE  !","  ENTITY^REFERENCE}  "/". 
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CHAPTER  4 - TOKENS 


4.0  TOKENS 

A STEP  file  can  be  represented  by  a sequence  of  tokens.  In  the  STEP  file 
structure,  a token  is  defined  to  be  a delimiter,  reserved  word,  keyword,  or 
simple  data  type.  The  definition  of  the  tokens  in  regular  expression  form  can 
be  found  in  Chapter  3.0  of  this  document.  Syntax  diagrams  for  the  simple  data 
types  can  be  found  in  Appendix  C of  this  document. 

4.1  TOKEN  SEPARATORS 

A token  separator  is  a character  or  a string  of  characters  that  can  appear 
between  any  two  tokens.  Any  number  or  combination  of  token  separators  may 
appear  together  between  any  two  tokens.  Token  separators  are  insignificant  and 
should  be  ignored  during  lexical  analysis.  Token  separators  may  not  appear 
within  integers,  real  numbers,  lists,  entity  references,  entity  identifiers, 
reserved  words,  keywords,  or  delimiters. 

Blanks  and  comments  are  token  separators.  The  blank  is  the  space  character.  A 
comment  is  a slash  followed  by  an  asterisk  "/*"  followed  by  any  number  of 
characters,  and  terminated  by  an  asterisk  immediately  followed  by  a slash 
Any  characters  appearing  inside  a comment  are  meaningless  to  the  file 
structure.  These  characters  are  intended  to  be  read  by  humans. 

4.2  DELIMITERS 

Delimiters  are  special  characters  or  combinations  of  special  characters  that 
serve  to  separate,  terminate,  or  otherwise  denote  meaningful  collections  of 
data.  Note  that  some  reserved  words  function  as  delimiters.  Delimiters  are 
1 isted  in  Table  4-1 
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Tabl e 4-1  Del imi ters 


CHARACTER(S) 

DELIMITER 

FUNCTION 

SCOPE 

reserved  word 

Begins  a scope  section 

ENDSCOPE 

reserved  word 

Terminates  a scope  section 

y 

comma 

Separates  fields 

j 

semicolon 

Terminates  an  entity  occurrence 

m 

equal  sign 

Separates  identifier  from  entity 
type  keyword 

( ) 

parenthesis 

Encloses  a list,  set,  array  or 
parameter  1 ist 

ENDSEC; 

reserved  word 

Terminates  a section 

ENDSTEP; 

reserved  word 

Terminates  a STEP  file 

/* 

slash- 

asterisk 

Begins  a comment 

*/ 

asteri sk- 
slash 

Terminates  a comment 

1 

slash 

Encloses  an  entity  export  list 

4.3  RESERVED  WORDS 

Reserved  words  are  special  strings  of  characters  associated  with  pre-designated 
meanings  or  functions.  Reserved  words  consist  of  uppercase  letters,  digits, 
underscore  characters,  and  possibly  a semicolon.  The  first  character  must  be  a 
letter.  Only  the  last  character  may  be  a semicolon.  Throughout  this  document. 
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a reserved  word  or  keyword  is  expressed  in  uppercase  letters.  These  reserved 
words  as  a whole  or  their  leading  portion  (not  including  the  semicolon)  cannot 
be  used  in  entity  type  keywords. 

List  of  Reserved  Words: 

SCOPE 

ENDSCOPE 

DATA; 

ENDSEC; 

STEP; 

HEADER; 

ENDSTEP; 


4.4  KEYWORDS 

Keywords  are  special  strings  of  characters  indicating  the  occurrence  of  an 
entity  of  a specific  type  on  the  STEP  file.  Keywords  consist  of  uppercase 
letters,  digits,  underscore  characters,  and  possibly  an  exclamation  mark.  The 
exclamation  mark  may  occur  at  most  once,  and  only  as  the  first  character  in  a 
keyword.  Keywords  beginning  with  the  exclamation  mark  are  "user-defined 
entity"  keywords.  Keywords  not  beginning  with  the  exclamation  mark  are 
standard  keywords.  The  first  character  in  standard  keywords  as  well  as  the 
second  character  of  user-defined  entity  keywords  (which  is  the  first  one 
following  the  exclamation  mark)  must  be  an  uppercase  letter. 

The  meaning  of  the  user-defined  entity  keywords  is  not  defined  in  the  standard 
but  is  rather  a matter  of  agreement  among  the  partners  exchanging  STEP  files. 

The  standard  keywords  are  specified  with  respect  to  their  appearance  in  the 
STEP  file  and  with  respect  to  their  meaning  in  this  standard.  For  the  header 
section  entities,  this  specification  is  given  in  chapter  6 of  this  document. 
For  the  data  section  entities,  the  appearance  is  defined  by  the  mapping  of 
EXPRESS  ENTITIES  onto  the  STEP  file  format  as  given  in  Appendix  C.  Their 
semantic  meaning  is  specified  in  STEP  DOCUMENT  4.1.2. 


4.5  SIMPLE  DATA  TYPES 

There  are  six  simple  data  types  utilized  in  STEP  exchange  format  files: 
integer,  real,  string,  entity  identifier,  entity  reference,  and  enumeration. 
The  detailed  definitions  of  the  data  types  are  presented  on  the  following 
pages. 


4.5.1  Integer 

An  integer  is  a string  of  one  or  more  digits,  optionally  preceded  by  a minus 
sign  or  a plus  sign  "+".  Integers  are  expressed  in  base  10.  If  there  is 
no  sign  associated  with  the  integer,  it  is  assumed  to  be  positive. 
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Examples ; 


Valid  STEP  Expressions 
of  Integer 

REMARKS 

16 

Positive  16 

+ 12 

Positive  12 

-349 

Negative  349 

012 

Positive  12 

00 

Zero 

Invalid  STEP  Expressions 
of  Integer 

REMARKS 

26  54 

Contains  blanks 

32.0 

Contains  decimal  point 

+ 12 

Contains  blank  between  sign  and  digits 

4.5.2  Real 


A Real  consists  of  a required  decimal  mantissa  followed  by  an  optional  decimal 
exponent.  The  mantissa  consists  of  an  optional  plus  sign  "+"  or  minus  sign 
followed  by  a string  of  one  or  more  digits,  followed  by  a decimal  point 
followed  by  a string  of  zero  or  more  digits.  A decimal  exponent  consists 
of  the  character  E followed  by  an  optional  plus  or  minus  sign,  followed 

by  one  or  more  digits. 

Exampl es: 


Valid  STEP  Expressions 
of  Real 

REMARKS 

+0.0E0 

0.0 

-O.OE-0 

0.0,  as  above  example 

1.5 

1.5 

-32.178E+02 

-3217.8 

0.25E8 

25  mill  ion 

0.E25 

0.0 

2. 

2.0 

05. 

5.0 
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Invalid  STEP  Expressions 

of  Real 

REMARKS 

1.2E3. 

Decimal  point  not  allowed  in  exponent 

1E05 

Decimal  point  required  in  mantissa 

1,000.00 

Comma  not  allowed 

3.E 

Digit{s)  required  in  exponent 

.5 

At  least  one  digit  must  precede  decimal 

point 

1 

Decimal  point  required  in  mantissa 

4.5.3  String 

A string  consists  of  an  apostrophe  followed  by  zero  or  more  characters, 

and  ended  by  a single  apostrophe  The  null  string  is  defined  by  two 

apostrophes  in  a row.  Within  a string,  a single  apostrophe  is  coded  as  two 
apostrophes  in  a row.  The  default  characters  to  be  used  within  a string  are 
the  printable  characters  defined  by  the  table  entries  32  through  126 
(inclusive)  of  ISO  6937/2.  This  table  is  presented  in  Appendix  B of  this 
document.  Four  examples  are  listed  below. 


Strina 

'CAT' 

Contents 

CAT 

'Don"t' 

t t t t 

Don't 

/ 

t ! 

Nul  1 

4.5.3. 1 Alternate  Character  Sets 

An  alternate  character  set  may  be  used  if  an  escape  sequence  is  coded  into  the 
character  string.  A description  of  a character  string  that  contains  an  escape 
sequence  is  defined  as  follows: 


1.  A single  apostrophe  to  start  the  character  string. 

2.  Any  number  of  characters  from  the  default  character  set. 

3.  A single  exclamation  point  immediately  followed  by  a single  colon  to  open 

or  begin  the  escape  sequence. 

4.  A reserved  word  to  indicate  the  character  set  table  to  be  used 

(e.g.,  GREEK  or  KANJI). 

5.  A comma  to  delimit  the  reserved  word. 
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6.  An  integer  value  that  corresponds  to  the  table  index  of  the  desired 

character  in  the  character  set  table. 

7.  A comma  to  delimit  the  integer  value. 

8.  Successive  integer  values,  each  separated  from  the  next  by  a comma. 

9.  The  final  integer  value  corresponding  to  a table  index  for  the  desired 

character. 

10.  The  closing  escape  sequence  character  pair 

(i.e.,  a single  colon  immediately  followed  by  an  exclamation  point). 

11.  Any  additional  characters  or  escape  sequences. 

12.  A single  apostrophe  to  close  the  character  string. 

In  order  to  avoid  being  interpreted  as  an  escape  sequence,  the  character 
must  be  encoded  in  a normal  character  string  by  being  repeated  once  as  a pair, 
(e.g., 

The  recognized  character  set  tables  and  their  associated  reserved  words  are 
presented  in  Appendix  B. 

4. 5. 3. 2 Maximum  String  Length 

The  maximum  length  of  a string  in  a STEP  file  is  32767  characters  not  counting 
the  beginning  and  ending  apostrophes. 
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4.5.4  Entity  Identifier 

An  entity  identifier  consists  of  an  at  sign  "0"  followed  by  an  unsigned 
integer.  The  integer  may  consist  of  any  combination  of  1 to  9 digits  as  long 
as  uniqueness  within  the  file  is  maintained.  Leading  zeroes  in  entity 
identifiers  are  not  significant.  The  entity  identifier  is  not  based  on  a 
relative  record  position.  They  need  not  be  sequentially  ordered  in  the  file. 
(See  Section  7.1). 


Valid  STEP  Expressions 
of  Entity  Identifiers 

REMARKS 

023 

0012 

Names  this  entity  with  identifier  23 

Names  this  entity  with  identifier  12 

Invalid  STEP  Expressions 
of  Entity  Identifier 

REMARKS 

0+23 

0500.1 

Contains  sign 

Contains  decimal  point 

4.5.5  Entity  Reference 

An  entity  reference  consists  of  a number  sign  followed  by  an  unsigned 

integer.  The  integer  may  consist  of  any  combination  of  1 to  9 digits.  This 
integer  value  must  equal  the  integer  value  within  some  previously  defined 
entity  identifier.  The  entity  reference  is  not  based  on  a relative  record 
position.  Leading  zeroes  are  not  significant. 

Examples: 


Valid  STEP  Expressions 
of  Entity  References 

REMARKS 

#23 

Refers  to  entity  occurrence  with 
identifier  23 

#023 

Refers  to  entity  occurrence  with 
identifier  23 

#694376142 

Refers  to  entity  occurrence  with 
' identifier  694376142 
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Invalid  STEP  Expressions 
of  Entity  References 

REMARKS 

74 

Does  not  begin  with  a number  sign  I 

#439A6 

Contains  alphabetic  character 

#1234567890 

Exceeds  nine  digits 

#0000000009 

Exceeds  nine  digits 

4.5.6  Enumeration 

An  enumeration  value  consists  of  some  combination  of  uppercase  letters  or 
digits  beginning  with  an  uppercase  letter.  The  entire  collection  of  uppercase 
letters  and  digits  is  bracketed  by  periods.  The  meaning  of  a given  value  is 
determined  by  the  conceptual  schema  which  defined  the  enumerated  list. 

Examples: 


Valid  STEP  Expressions 
of  Enumerated  Values 

REMARKS 

.FALSE. 

Indicates  a value  of  FALSE 

.STEEL. 

Indicates  a value  of  STEEL 

Invalid  STEP  Expressions 
of  Enumerated  Values 

REMARKS 

.TRUE 

Missing  ending  period 

.123. 

Did  not  start  with  an  alphabetic 
character. 
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CHAPTER  5 - STRUCTURED  DATA  TYPES 


5.0  STRUCTURED  DATA  TYPE 

The  list  is  the  only  structured  data  type  in  the  STEP  file  structure. 


5.1  LIST 

A list  is  a homogeneous  collection  of  instances  of  simple  or  structured  data 
types.  It  is  begun  by  a left  parenthesis  "("  and  terminated  by  a right 
parenthesis  ")".  Instances  are  delimited  by  commas.  Lists  may  be  nested 
arbitrarily  deep. 


Examples: 


List  of  List  of  Real 
List  of  Integer 
List  of  String 


({0.0,  1.0,  2.0),  (3.0,  4.0,  5.0)) 
(0,1, 2, 3, 7, 2, 4) 

('CAT',  'HELLO') 
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CHAPTER  6 - HEADER  SECTION 


6.0  HEADER  SECTION 

The  HEADER  section  contains  information  that  is  applicable  to  the  entire 

exchange  format  file.  This  section  must  be  present  in  any  STEP  file.  Refer  to 
Appendix  A for  a complete  example. 

6.1  HEADER  SECTION  ENTITIES 

These  entities  are  to  aid  in  the  overall  data  exchange  process.  The  HEADER 

section  entities  follow  the  same  general  syntax  of  the  DATA  section  entities, 
which  simplifies  postprocessor  parsing  software.  HEADER  section  entity 
occurrences  are  defined  in  the  following  manner: 

ENTITY_TYPE  ( one  or  nwre  attributes); 

where 

Entity  Type  - A keyword  through  which  the  type  of  the  entity  is 
identified.  The  keywords  correspond  to  those  listed  in 
Table  6-1.  The  keyword  is  delimited  by  a left 

parenthesis  "(". 

Attribute  - An  instance  of  a simple  or  structured  data  type.  The 

correspondence  of  attributes  and  keywords  is  maintained 
in  Table  6-1.  Attributes  are  separated  by  commas.  The 
final  attribute  is  delimited  by  a right  parenthesis  ")". 
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Table  6-1  Kevword-To-Attri bute  Relationships 


-EADEH  SECTIM  ENTITY  OEEINITIOIS 


ENTITY  aYWtO 

1 

1 iTTtiam 

1 NAM 

1 

OATATYM 

1 

1 ATTRigUT* 
j POSITIOI 

STATUS  Of 
ENTin  Ol 
ATTtlBiTt 

1 

OESCIIPTIQM  j 

TILE.IOENTIElCATiai 

1 

1 

I FILE  NAM 

1 

1 

1 

1 

1 

i 

1 String 

1 

1 

1 

1 

1 

1 

1 

1 1 

I 

I 

I 

I 

*«guir«d 

loquirad 

1 1 

1 This  string  of  eharsettrs  is  | 

j Lsad  to  naaq  this  STEP  fits.  | 

1 It  IS  intandaq  to  Da  ustd  as  a | 

I parson- to* DPrson  comuMCAtion  1 

I Datwaan  sanpar  arq  rtctivar.  j 

1 Thara  ara  no  spacial  restric- 
1 tions  on  tha  eontant  of  this  | 

fiald.  1 

1 

DATE 

i 

1 

1 Strin* 

1 

1 

I 

2 

I 

I 

Rtquirad 

1 1 

1 This  idantifias  tha  Local  data  j 

1 and  tima  tha  fila  aas  crtatao,  | 

1 taprassad  aa  tyyy  q*  do  hh  xm  ;s  1 
j This  fonrqt  eorrtsoonoa  to  :na  of 
thosa  spacifiad  in  ISO  Standard  1 

1 20H.  1 

1 AUTHCi 

1 

1 

1 List  of 
String 

1 

I 3 

I 

I 

(•quirM 

1 This  idantifias  tha  parson  j 

rtspenstbla  for  crtating  tna  i 

I tacnanga  fomqt  fits  and  tha  | 

nqiling  addrass  of  that  parson,  j 

ORGAMlZATtSI 

1 

1 

1 List  of 

I String 

1 

4 

1 

(•OAirod 

1 1 

1 This  idantifias  tha  group  or  1 

i organitation  aith  q^oq  tha  { 

1 author  is  assactatsd.  | 

1 

STEP  VCtSIOl 

1 

1 SCrinf 

1 

■ ’ 

Egqjirad 

1 1 

1 This  indicataa  tha  STEP  varsien  1 

I iqad  in  crtating  tha- fila.  | 

1 ONEPKOaSSOI  VOniOH 

1 

1 

1 String 

1 

1 

1 

1 6 

1 

1 

Eiqjirod 

1 This  idantifias  tha  praprocassor  | 
j softuara  usad  to  creata  tha  STEP  j 
j fila.  It  includas  tha  sof thara  j 
product  naa»  and  varsion.  j 

1 

1 GRIGINAriNG  SYSTEM 

1 

1 

1 Strin9 

1 

7 

1 

Atquirad 

1 < 

1 This  idantifias  tha  CAO/Can/CIN  | 

1 systaa  fro*  qiicn  tna  data  m ' j 

1 this  STEP  fila  originattd.  j 

flLE.OESCHIPTIO* 

1 

1 

OESCRIPTIOH 

1 

1 

1 

1 String 

1 

1 

1 

1 1 

1 

1 

(•quirgd 

(•qjirod 

1 1 

iThis  is  an  informal  dascnotion  | 

of  tha  eontants  of  this  STEP  j 

1 fila.  1 

1 ; 

IW.LEVtU 

1 

1 IMPIEMMYATISI  LEVn 

1 

1 

1 

1 

1 String 

1 

1 

1 

1 

1 1 

1 

1 

1 

toquirad 

Raquirad 

1 1 

1 This  indicataa  tha  raouirad  ! 

implaaqntation  laval  of  tna  ! 

1 postproctssor  softuara  m ordar  | 
j for  it  to  cooplattly  proctss  all  ' 
j of  tha  data  in  this  step  fila.  | 

1 Tha  actual  valuas  for  this  aiil 

1 Da  datarminad  at  a lattr  data.  | 

CUSSIFICATtOM 

1 

acuain  cussieicatioh 

1 

1 

t 

1 String 

1 

1 

1 

1 

Optional 

laqjirad 

1 i 

1 This  idantifias  tha  rastnetions  1 

1 on  tha  usa  of  tha  information  | 

eontainad  in  this  fila.  Tha  | 

1 dafault  is  an  aaqty  string.  | 

NAXSIC 

1 

MXIIU)  StCMirtCAHT  DIGIT 

1 

j 

1 

1 Intoggr 

1 

1 

1 

J 

1 

1 1 

1 

1 

1 

1 

Optional 

Sa^irad 

1 This  indicatas  tha  nurbar  of  j 

1 dacimal  digits  of  significanca  1 

1 that  can  Da  raprasantad  1 

1 aceurataly  on  this  fila. 

1 

J — 1 
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6.1.1  HEADER  Section  User  Defined  Entities 

User  defined  entities  may  be  placed  into  the  HEADER  section  under  specific 
restrictions.  Post-processor  translator  software  should  be  prepared  to  ignore 
those  entities  it  does  not  recognize.  This  precaution  will  allow  the  future 
introduction  of  new  HEADER  section  entities  without  adversely  affecting  any 
existing  translator  software. 


The  four  restrictions  that  limit  the  specification  of  user  defined  entities  are 

1 i sted  bel ow. 

1.  User  defined  entities  must  conform  to  the  same  general  syntax  of  all  HEADER 
section  entities  with  the  exception  that  the  entity-type  keyword  is 
immediately  preceded  by  an  exclamation  point 

2.  User  defined  entities  may  not  appear  as  embedded  entities  within  a standard 
entity. 

3.  User  defined  entities  may  only  be  embedded  within  other  user  defined 
entities. 

4.  User  defined  entities  may  not  use  any  delimiters,  simple  data  types,  or 
structured  data  types  beyond  those  defined  in  the  standard. 


Examol e 
HEADER; 


IMP.LEVEL  ('BREP  - LEVEL  1.0'); 

!A_SPECIAL_ENTITY  ('ABC', 123);  /*  SAMPLE  USER  DEFINED  ENTITY  */ 

ENDSEC; 
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CHAPTER  7 - DATA  SECTION 


7.0  DATA  SECTION 

The  DATA  section  is  used  to  define  the  product  data  to  be  transferred.  It 
contains  occurrences  of  entities  defined  in  the  STEP  conceptual  schema.  This 
section  must  appear  in  the  file.  Throughout  the  DATA  section,  entity 
occurrences  must  be  defined  before  they  may  be  referenced.  Refer  to  Appendix  A 
for  a complete  example. 

7.1  DATA  SECTION  ENTITIES 

DATA  section  entity  occurrences  are  defined  in  the  following  manner: 

ENTITY.IDErrriFIER  « ENTITY.TYPE  optional  SCOPE  Structure 
(one  or  more  attribute  values); 


where 

Entity  Identifier 
Entity  Type  - 


Optional  SCOPE 
Structure 

Attribute  - 


Embedded  Entity  - 


Refer  to  the  definition  given  in  section  4.5.4. 

A keyword  through  which  the  type  of  the  entity  is 
identified.  The  keyword  is  delimited  by  a left 
parenthesis  "{".or  a space  " ".  These  keywords 
correspond  to  the  entities  defined  in  the 
conceptual  schema.  Refer  to  the  definition  given 
in  section  4.4. 

See  the  discussion  in  Chapter  7.2. 


An  instance  of  a simple  or  structured  data  type, 
or  an  instance  of  an  embedded  entity.  Attributes 
are  separated  by  commas.  The  final  attribute  is 
delimited  by  a right  parenthesis  ")".  The  entire 
entity  occurrence  is  delimited  by  a semicolon 

An  embedded  entity  is  an  entity  that  is  serving  as 
an  attribute  of  the  entity  in  which  it  is 
embedded.  Syntactically,  it  appears  like  an 
entity  occurrence  that  is  missing  the  entity 
identifier,  the  equal  sign  and  the  final 

semicolon  Under  circumstances  described  in 

Normative  Annex  C,  the  entity  type  keyword  may  be 
omitted. 

The  significance  of  an  embedded  entity  is 
discussed  within  Normative  Annex  C,  "Mapping  From 
EXPRESS  To  Physical  File  Structure". 
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7.1.1  Optional  Values 

When  an  optional  attribute  value  is  not  provided,  all  delimiters  that  would 
normally  appear  when  the  value  is  present  will  be  maintained. 

Example:  @32  - NO0E(1.0,,2.0/ABC'); 

I 

This  entity  has  an  optional  second  attribute  value 
that  is  not  provided  in  this  occurrence. 

7.2  SCOPE  STRUCTURE 

The  SCOPE  structure  within  entity  definitions  is  a mechanism  for  providing  a 
scope  of  reference. 

7.2.1  Syntax 

The  SCOPE  structure  is  optional  for  all  entity  types.  If  it  appears,  it  must 
appear  following  the  entity  type  keyword  and  before  the  actual  defining 
attributes  of  the  entity  in  which  it  is  appearing.  It  is  begun  by  the  reserved 
word  "SCOPE".  Following  that  are  any  number  of  entity  occurrences. 
Syntactically,  it  is  legal  for  the  entity  occurrences  to  be  of  any  type  of 
entity.  The  structure  is  terminated  by  the  reserved  word  "ENOSCOPE",  After 
the  ENOSCOPE  reserved  word,  an  optional  entity  export  list  may  appear. 
Entities  within  a scope  structure  may  themselves  have  scope  sections.  See 
Chapter  3.4  for  the  formal  syntactical  descriptions. 

7.2.2  Referencabi 1 itv 

In  a similar  manner  to  the  scoping  of  variables  in  common  structured 
programming  languages,  entities  defined  in  a SCOPE  structure  are  not  "visible" 
to,  or  referencable  by,  entities  that  reside  in  outer  scopes  unless  they  are 
explicitly  made  "visible"  by  means  of  their  inclusion  in  the  entity  export 
list.  The  defining  attributes  of  the  entity  may  refer  to  any  entity 
occurrences  in  its  SCOPE  structure.  Entities  which  need  to  be  "shared"  i.e., 
multiply  referenced,  by  a number  of  entities,  need  to  be  defined  within  a scope 
that  is  common  to  the  referencing  entities. 

7.2.3  Behavior 

The  behavior  of  entity  occurrences  which  appear  within  a SCOPE  structure  is 
defined  as  follows: 

0 Modifications  of  the  parent  entity  will  be  passed  onto  the  scoped 
entity(s)  if  and  only  if  that  modification  is  applicable  to  the 
scoped  entity(s).  For  example,  transformation  of  the  parent  entity 
will  transform  all  the  scoped  entities  to  which  the  transformation 
operation  applies;  deletion  of  the  parent  entity  will  delete  all  the 
scoped  entities  (deletion  applies  to  entities  of  any  type).  Approval 
of  the  parent  entity  will  approve  all  the  scoped  entities  to  which 
this  operation  appl ies. 
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0 Scoped  entity  occurrences  made  "visible"  by  the  entity  export  list 
are  considered  in  the  same  scope  of  reference  as  the  parent  entity. 
Other  entities,  capable  of  referencing  the  parent  entity,  may  legally 
reference  the  entities  appearing  in  the  entity  export  list. 

0 When  modifications  to  an  exported  entity  conflict  with  modifications 
performed  on  the  parent  entity,  the  modifications  on  the  parent 
entity  will  take  precedence.  For  example,  if  an  exported  entity  is 
referenced  by  a given  transformation  matrix  (TMi),  and  the  parent 
entity  is  referenced  by  a different  transformation  matrix  (TM2), 
the  exported  entity  is  transformed  by  TM2  and  not  TM^. 

Some  examples  of  the  use  of  scoping  follow: 

Example  1 

(31  =*  TRIANGLE 

SCOPE 

02  - POINT  (0.0, 0.0, 0.0); 

03  - POINT  (0.0,1.0,0.0) ; 

04  » POINT  (3. 0,1. 0,0.0); 

ENDSCOPE 

(LINE{#2,#3),LINE(#3,#4),LINE(#4,#2)); 

In  the  above  example  the  entity  TRIANGLE  is  defined  by  three  LINE  entities. 
Since  the  LINE  entities  are  embedded  within  the  TRIANGLE,  they  have  an 
existence  dependency  upon  the  TRIANGLE.  The  POINT  entities  -which  define  the 
lines  are  also  dependent  upon  the  TRIANGLE  for  their  existence.  Since,  the 
POINT  entities  have  entity  identifiers,  they  are  available  to  be  referenced  by 
the  embedded  LINE  entities  in  the  attribute  list. 

Example  2 

01  - ASSEMBLY 

SCOPE 

012  - PART  {'PART  #74A',,,); 

013  - PART  ('PART  #68B',,,); 

014  - PART  ('PART  #12C',,,); 


ENDSCOPE/#13,  #14/ 

((#6, #7),,,); 

015  - APPROVAL  {(#13),  'JOHN  SMITH  APP.  AUTHORITY'); 
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In  the  above  example,  the  PART  entities  with  entity  identifiers  013  and  014  are 
exported,  or  made  referencabl e , from  the  SCOPE  structure  of  the  ASSEMBLY 
entity.  Following  the  defining  attributes  of  the  ASSEMBLY  entity,  an  APPROVAL 
entity  occurs  which  references  the  PART  entity  with  entity  identifies  013.  In 
this  case,  it  is  only  that  particular  PART  entity  which  is  approved,  while  at 
the  same  time  maintaining  the  existence  dependency  of  that  PART  entity  upon  its 
parent  ASSEMBLY. 

7.3  EXTERNAL  REFERENCES 

An  external  reference  is  the  mechanism  by  which  an  entity  in  a STEP  file  may 
refer  to  information  that  is  physically  external  to  the  STEP  file  being 
processed.  The  type  of  information  that  is  referred  to  can  be  of  any  type,  not 
necessarily  geometric  in  nature.  An  external  reference  can  be  thought  of  as  an 
extension  of  the  basic  entity  reference  capability  that  has  already  been 
provided  (see  Chapter  4.5.5).  A number  of  specialized  entities  have  been 
formulated  to  support  external  references.  Specifically,  these  are  the  EXPORT, 
LIBRARY,  and  EXTERNAL  REFERENCE  entities.  Their  definitions  and  the  details  of 
their  use  can  be  found  in  the  Conceptual  Schema  document  (STEP  document  4.1.2). 

7.4  INDEX  OF  ENTITY  ALIASES 

An  INDEX  entity  has  been  formulated  which  allows  the  establishment  of  a 
character  string  alias(s)  for  a given  entity.  Its  definition  and  the  details 
of  its  use  can  -be  found  in  the  Conceptual  Schema  document  (STEP  document 
4.1.2). 

7.5  DATA  SECTION  USER  DEFINED  ENTITIES 

User  defined  entities  may  be  placed  into  the  DATA  section  under  specific 
restrictions.  Post-processor  translator  software  should  be  prepared,  to  ignore 
those  entities  it  does  not  recognize.  This  precaution  will  allow  the  future 
introduction  of  new  DATA  section  entities  without  adversely  affecting  any 
existing  translator  software. 

The  four  restrictions  that  limit  the  specification  of  user  defined  entities  are 
1 i sted  bel ow. 

1.  User  defined  entities  must  conform  to  the  same  general  syntax  of  all  DATA 
section  entities  with  the  exception  that  the  entity-type  keyword  is 
immediately  preceded  by  an  exclamation  point 

2.  User  defined  entities  may  not  appear  as  embedded  entities  within  a standard 
entity. 

3.  User  defined  entities  may  only  be  embedded  within  other  user  defined 
entities. 

4.  User  defined  entities  may  not  use  any  delimiters,  simple  data  types,  or 
structured  data  types  beyond  those  defined  in  the  standard. 
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example 

DATA; 

01»PT{i. 0,2. 0,3.0);  /*  STANDARD  POINT  ENTITY  */ 

@2»PT(1. 0,2. 0,5.0);  ' 

012-!MYCURVE(O.O,O.O,O.O,1.O,,,);  /*  SAMPLE  USER  DEFINED  ENTITY  */ 

ENDSEC; 
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APPENDIX  A - SAMPLE  STEP  EXCHANGE  FORMAT  FILE 


A.l  STEP  FILE  FORMAT 

An  example  STEP  file  is  presented  below. 


STEP; 


HEADER; 

FILE_IDENTIFICATION{'EXAMPLE  STEP  FILE  #1' 19880211 . 153000' ,( 'JOHN  DOE'  'ACME 
INC.'  'METROPOLIS  USA'), ('ACME  INC.  A SUBSIDIARY  OF  GIANT  INDUSTRIES' 
'METROPOLIS  USA'), 'STEP  VERSION  1 .0' , 'CIM/STEP  VERSI0N2 ',' SUPER  CIM  SYSTEM 
RELEASE  4.0'); 

FILE_DESCRIPTION('THIS  FILE  CONTAINS  A SMALL  SAMPLE  STEP  MODEL' );  IMP_LEVEL 
('BREP-LEVEL  1.0'); 

ENDSEC; 

DATA; 

/ * 


THE  FOLLOWING  13 
(?1-PT{0. 0,0. 0,0.0) 

(a2-PT(0. 0,1. 0,0.0) 

(a3«PT(l. 0,0. 0,0.0) 

• (311-VX{#1); 

(?12*VX(#2); 

@13-VX(#3); 

016»ED(#11,#12); 
(ai7.ED(#ll,#13); 
018-ED(#13,#12); 

021»EO  STRC(#17,0) 
022-ED_STRC(#18,O) 
023»ED_STRC(#16,1) 
024-ED_LOOP({#21,#22,#23)); 


ENTITIES  REPRESENT  A TRIANGULAR  EDGE 
/*  THIS  IS  A POINT  ENTITY  */ 


LOOP 


/*  THIS  IS  A VERTEX  ENTITY  */ 


/*  THIS  IS  AN  EDGE  ENTITY  */ 


/*  THIS  IS  AN  EDGE  STRUCTURE  ENTITY  */ 


/*  THIS  IS  AN  EDGE_LOOP  ENTITY  */ 


*/ 


/* 

ANOTHER  WAY  OF  REPRESENTING  THE  TRIANGULAR  EDGE  LOOP  FOLLOWS:  */ 

011O-VX(PT(O. 0,0. 0,0.0)); 

012O-VX(PT(O. 0,1. 0,0.0)); 

013O»VX(PT(1. 0,0. 0,0.0)); 

016O-ED{#11O,#12O); 

017O-ED(#11O,#13O); 

018O-ED{#13O,#12O); 

024O»ED  L00P((ED_STRC(#170,0),ED_STRC(#ia0,0),ED_STRC(#160,l))) ; 


(Continued  on  next  page) 


A-1 


N279 


ISO  TC184/SC4/WG1  ANNEX  B (Normative)  September  iSS3 

(Document  4.2.1  Draft  Paper) 


(STEP  file  example  continued) 

/* 

YET  ANOTHER  WAY  OF  REPRESENTING  THE  TRIANGULAR  EDGE.LOOP  FOLLOWS:  */ 

011OO-VX(PT(O. 0,0. 0,0.0)); 

(31200-VX(PT(0.0,1.0,0.0)) ; 

013OO»VX{PT(1. 0,0. 0,0.0)); 

02400-ED  LOOP 
SCOPE 

@1600-ED(#1100,#1200) ; 

017OO-ED{#11OO,#13OO) ; 

018OO-ED(#13OO,ii^l2OO); 

ENDSCOPE 

((ED_STRC(#1700,0),ED  STRC(#1800,0) ,ED  STRC(#1500, 1) ) ) ; 

/*  OTHER  SYNTACTICAL  REPRESENTATIONS  WERE  POSSIBLE.  THE  PREVIOUS  THREE 

EXAMPLES  ARE  REPRESENTATIVE  OF  COMMON  APPROACHES.  IT  SHOULD  BE  NOTED 
THAT  EACH  APPROACH  PRESENTED  HERE  CARRIES  DIFFERENT  SEMANTICS.*/ 

ENDSEC; 

ENDSTEP; 


NOTE:  This  example  STEP  file  has  been  presented  in  a line-oriented  or 

record -ori ented  manner  in  order  to  aid  readability.  Unnecessary 

spaces  have  also  been  added  to  aid  readability.  Note  that  an  ordinary 
STEP  file  is  not  aligned  in  this  manner,  but  is  instead  a continuous 
stream  of  characters. 
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B.O  . THE  GRAPHICAL  ALPHABET 


The  graphical  alphabet  of  this  standard  comprises  an  extendible  set  of 
alphabets.  Each  alphabet  is  identified  by  a reserved  word.  Each  alphabet 
contains: 

1)  a listing  of  the  graphical  representations  of  all  symbols  of  the 
al phabet. 

2)  an  algorithm  that  uniquely  maps  each  of  these  symbols  onto  a 
positive  integer  (called  decimal  coded  character,  DCC). 

The  representation  of  these  DCC's  on  the  physical  file  is  subject  to  the 
various  presentation  techniques  allowed  in  this  standard  (see  Appendix  D of 
this  document).  At  this  time,  only  the  "clear  text  encoding"  is  defined  (see 
also  ESC_CHAR,  ESC_SEQ,  and  ESC_ITEM  in  Table  3-3  "Token  definition"). 

At  this  time  the  following  alphabets  are  defined: 


Reserved  Word 


meaning 


IS06937 

GREEK 

KANJI 


the  basic  character  set 
the  Latin  alphabet 
the  Greek  alphabet 
the  Kanji  alphabet 


Other  alphabets  will  be  included  in  this  standard: 

an  alphabet  for  drafting  symbols 
alphabets  for  various  other  applications 

B.l  BASIC  CHARACTER  SET  (Escape  Sequence  Reserved  Word  » IS06937) 

The  character  set  used  to  encode  STEP  files  is  ASCII  defined  by  ISO  6937/1. 
Furthermore,  only  the  printable  characters  defined  by  the  table  entries  32 
through  126  (inclusive)  are  ever  allowed  within  a STEP  file. 
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The  decimal  value  of  the  alphabet  element  appears  in  the  first  line  of  each 
pair  of  lines  illustrated  below.  The  graphical  representation  of  the  alphabet 
element  appears  in  the  second  line  where  G(i)  denotes  the  grapnical 
representation  of  the  decimal  i.  The  international  monetary  symbol  cannot  be 
printed  in  the  text  system  that  generates  this  report,  therefore  a dollar  sign 
i s shown  for  G(36) . 


Table  B-1  Graphical  Character  Set 


32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

SPACE 

1 

II 

# 

S 

% 

/ 

( 

) 

* 

+ 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

• 

• 

/ 

0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

58 

59 

60 

61 

62 

63 

64 

65 

66 

67 

68 

69 

70 

• 

» 

< 

M 

> 

0 

A 

B 

C 

D 

E 

F 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 

81 

82 

83 

G 

H 

I 

J 

K 

L 

M 

N 

0 

P 

Q 

R 

S 

84 

85 

86 

87 

88 

89 

90 

91 

92 

93 

94 

95 

96 

T 

U 

V 

W 

X 

Y 

Z 

[ 

\ 

] 

A 

- 

\ 

97 

98 

99 

100 

101 

102 

103 

104 

105 

106 

107 

108 

109 

a 

b 

c 

d 

e 

f 

g 

h 

i 

j 

k 

1 

m 

110 

111 

112 

113 

114 

115 

116 

117 

118 

119 

120 

121 

122 

n 

0 

P 

q 

r 

s 

t 

u 

V 

w 

X 

y 

z 

123 

124 

125 

126 

{ 

1 

} 

— 
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B. 1 . 1 Subsets 

The  range  of  characters,  32  through  126,  are  further  refined 
subsets. 


B.  1 .2  Digit 


ASCII 

Decimal  Number 

Character 

Meaning 

48 

0 

Zero 

49 

1 

One 

50 

2 

Two 

51 

3 

Three 

52 

4 

Four 

53 

5 

Five 

54 

6 

Six 

55 

7 

Seven 

56 

8 

Eight 

57 

9 

Nine 
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ASCII 

Decimal  Number 

Character 

Meaning 

65 

A 

UPPERCASE  A 

66 

B 

UPPERCASE  B 

67 

C 

UPPERCASE  C 

68 

0 

UPPERCASE  D 

69 

E 

UPPERCASE  E 

70 

F 

UPPERCASE  F 

71 

G 

UPPERCASE  G 

72 

H 

UPPERCASE  H 

73 

I 

UPPERCASE  I 

74 

J 

UPPERCASE  J 

75 

K 

UPPERCASE  K • 

76 

L 

UPPERCASE  L 

77 

M 

UPPERCASE  M 

78 

N 

UPPERCASE  N 

79 

0 

UPPERCASE  0 

80 

P 

UPPERCASE  P 

81 

Q 

UPPERCASE  Q 

82 

R 

UPPERCASE  R 

83 

S 

UPPERCASE  S 

84 

T 

UPPERCASE  T 

85 

U 

UPPERCASE  U 

86 

V 

UPPERCASE  V 

87 

w 

UPPERCASE  W 

88 

X 

UPPERCASE  X 

89 

Y 

UPPERCASE  Y 

90 

Z 

UPPERCASE  Z 

95 

- 

Underscore 
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B. 1 .4  Lower 


ASCII 

Decimal  Number 

Character 

Meaning 

97 

a 

lowercase  A 

98 

b 

lowercase  B 

99 

c 

lowercase  C 

100 

d 

lowercase  D 

101 

e 

lowercase  E 

102 

f 

lowercase  F 

103 

g 

lowercase  G 

104 

h 

lowercase  H 

105 

i 

lowercase  I 

106 

j 

lowercase  J 

107 

k 

lowercase  K 

108 

1 

lowercase  L 

109 

m 

lowercase  M 

110 

n 

lowercase  N 

111 

0 

lowercase  0 

112 

P 

lowercase  P 

113 

q 

lowercase  Q 

114 

r 

lowercase  R 

115 

s 

lowercase  S 

116 

t 

lowercase  T 

117 

u 

lowercase  U 

118 

V 

lowercase  V 

119 

w 

lowercase  W 

120 

X 

lowercase  X 

121 

y 

lowercase  Y 

122 

z 

lowercase  Z 
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B.2  THE  LATIN  ALPHABET  (IS06937) 


IS06937/2  is  used  as  a basis  for  coding  the  "decimal  coded  character" 
representations  (DCC)  of  Latin  characters.  The  coding  method  B of  the  ISO 
standard  is  used.  According  to  this  method,  Latin  characters  are  coded  by  one 
or  two  pairs  of  integers: 

(1)  n^r\2  n2/ni 

(2)  r\^r\2 

(3)  - n2/ni 


where  n^ 

"3 

"2 

Syntactically  the 


i s 

greater  than 

or 

equal 

to 

8 

and 

1 ess 

than 

or 

equal 

to 

15 

i s 

greater  than 

or 

equal 

to 

0 

and 

less 

than 

or 

equal 

to 

7 

i s 

greater  than 

or 

equal 

to 

0 

and 

less 

than 

or 

equal 

to 

7 

i s 

greater  than 

or 

equal 

to 

0 

and 

1 ess 

than 

or 

equal 

to 

7 

three  forms  are  distinguished  as 


<one_to_seven> 
<eight_to_fi fteen> 
<forml> 

<form2> 

<form3> 


1 2 3 1 4 1 5 1 6 I 7 

8 9 10  I 11  1 12  I 13  I 14  I 15 

<form2>  <form3> 

<eight_to_fi fteen>  | <one_to_seven> 
<one  to  seven>  i <one  to  seven> 


The  second  form  defines  implicitly  n2  • n^  » 0. 

The  third  form  defines  implicitly  n^  - 8,  n3  » 0. 

From  this  representation  method  the  DCC  is  defined  as  follows: 
DCC  = 16*(8*(  16*(n4-8)  + 03)  + n2  ) + n^ 
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The  algorithm  (formulated  in  F0RTRAN77)  to  derive  the  4 numbers  n^-n^ 
a DCC  is  as  follows: 

subroutine  tran{dcc,nl,n2,n3,n4) 

integer  dec, varl ,var2,nl ,n2,n3,n4 

varl»dcc 

var2*varl/16 

nl»varl-{16*var2) 

varl»var2 

var2»varl/8 

n2»varl- (8*var2) 

varl»var2 

var2»varl/16 

n3«varl - ( 15*var2) 

n4»var2+8 

return 

end 
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B.3  GREEK  CHARACTER  SET  (Escape  Sequence  Reserved  Word  = GREEK) 

The  Greek  character  set  is  conveyed  by  the  character  set  encoding  in  ISD/DIS 
6937/7  "Information  processing  --  Coded  character  sets  for  text  communication 
--  Part'7  Greek  graphic  characters". 
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APPENDIX  C - ENTITY  SYNTAX  ON  THE  PHYSICAL  FILE 

In  this  appendix,  words  typed  in  lowercase  letters  represent  items  that  were 
previously  defined  by  the  file  structure  syntax  (See  Tables  3-3  and  3-4). 


AXIS1_PLACEMENT-AXIS  « entity_r«f •r«nc«  | DIRZCTIOM  . 

AXISl  PLACEMENT-LOCATION  ■ entity  reference  1 POINT  . 
AXIS1~PLACEMZNT  « "(" 

[ AXISl  PLACEMENT-AXIS  ] 

AXIS 1_PLACEMENT- LOCATION 

•» ) It 

AXIS2  PLACEMENT-AXIS  - entity  reference  | DIRECTION  . 
AXIS2~PLACEMENT-LOCATION  » entity_ref erence  | DIRECTION  . 
AXIS2“PLACEMENT-REF  DIRECTION  - entity_ref erence  | DIRECTION  . 
AXIS2_PLACEMENT  - "T'' 

[ AXIS2_PLACEMENT-AXIS  ] 
AXIS2_PLACEMENT-LOCATION  " , ” 
c AXIS2_PLACEMENT-R£F  DIRECTION  ] 

AXIS  PLACEMENT  - AXIS2  PLACEMENT 

1 AXISl”PLACEMENT  . 

BE2IER_CURVE-CONTROL  POINTS  - list  . 

BEZIER  CURVE-DEGREE  - integer  . 

BE2IER”cURVE-FORM  number  - "."String"."  . 

BEZIER  CURVE-KNOTS  « list  . 

BEZIER”cURVE-RATIONAL  « logical  . 

BEZIER  CURVE-SELF_INTERSECT  ■ logical  . 

bezier'curve-weights  « list  . 

BEZIER_CnRVE  » "(" 

BEZIER_CURVE -CONTROL  POINTS  "," 
BEZIER_CURVE-DEGREE  "," 

[ BEZIER  CURVE -FORM_NUMBER  ] "," 
BEZIER_CURVE-KNOTS  "," 

BEZIER  CURVE-RATIONAL  "," 

BEZIER”cURVE-SELF  INTERSECT 
BE Z I ER”cURVE - WE I GHTS 
")  " . 

BEZIER_SURFACE-C0NTR0L  POINTS  • list  . 
BEZIER_SURFACE-FORM_NUMBER  • "."string"."  . 

BEZIER  SURFACE-U  DEGREE  - integer  . 

BEZIER~SURFACE-u”rATIONAL  ■ integer  . 

BEZIER_SURFACE-U~UNIFORM  » logical  . 

BEZIER  SURFACE-U  UPPER  « integer  . 

BEZIER"surFACE-v“dEGREE  - integer  . 

BE2IER”SURFACE-V  rational  « logical  . 

BE2IER“SURFACE-v“UNIFORM  « logical  . 

BEZIER”sURFACE-v“uPPER  - integer  . 

BEZIER~SURFACE-WEIGHTS  - list  . 

BEZIER  SURFACE  « "(" 

“ BEZIER  SURFACE-CONTROL_POINTS 

[ BEZIER_SURFACE-F0RM_NUMBER  ] 
BEZIER_SURFACE-U  DEGREE  " 

BEZIER  SURFACE-U  RATIONAL 
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BE2IER_SURFACE-U  UNIFORM  " , " 
BEZIER_SURFACE-U“UPPER  ” , " 

BEZIER  SURFACE-V  DEGREE  " , " 

be2ier"surface-v”rational 
be2Ier”surface-v”uniform  " , " 
bezier”surface-v~upper 

[ BEZIER_SURFACE-WEIGHTS  ] 

. 

BOUNDED_CURVE  » COMPOSITE  CURVE 
TRIMMED  CURVE 
B SPLINE_CURVE 
BEZIER_CURVE 
LINE_SEGMENT  . 

BOUNDED_SURFACE  - CURVE_BOUNDED  SURFACE 

RECTANGULAR  TRIMMED_SURFACE 
BEZIER_SURFACE 
B_SPLINE_SURFACE  . 

B SPLINE_CURVE-CONTROL_POINTS  » list  . 

B~SPLINE  CURVE-DEGREE  ■ integer  . 
b“sPLINE”cURVE-FORM_NUMBER  - "."string"."  . 
b“sP LI NE“cURVE- KNOTS  » list  . 
b“sPLINE"cURVE-KNOT  MULTIPLICITIES  « list  . 

B“sPLINE  curve -rational  - logical  . 
b“sPLINEIcURVE-SELF_INTERSECT  - logical  . 

B~SPLINE  CURVE-UNIFORM  « logical  . 

b“sP LI NE“cURVE -UPPER  INDEX  ON  CONTROL  POINTS  - integer  . 
B^SPLINE  CURVE-WEIGHTS  « list”. 

B_SPLINE”cDRVE  - "(" 

B SPLINE  CURVE -CONTROL  POINTS 

b”spline“curve-degree 

[”b  spline  CURVE-FORM  NUMBER  ] " , " 

[ b”spline”curve-knots  ] 

B SPLINE  CURVE-KN0T_MULTIPLICITIES  " , " 

b”spline”curve-rational 
b”spline”curve-self  intersect  "," 
b”spline”curve-uniform  "," 
bIspline”curve-upper  index  on  control  points 

B_S PLINE“cURVE-WEIGHf S 

n ) it  . — 

B SPLINE_SURFACE-CONTROL_POINTS  » list  . 
b”sPLINE  SURFACE-FORM  NUMBER  ■ "."string"."  . 
b”spLINE2suRFACE-U  degree  - integer  . 
b”spline  surface -u”knots  - list  . 
b"spline”surface-u”multiplicities  » list  . 
b”spline”surface-u_rational  » logical  . 
b”sPLINE”sURFACE-U  uniform  - logical  . 

B SPLINE”surface-u”upper  » integer  . 
b”spline“surFACE-v”degREE  - integer  . 
b”spline  surface-v”knots  « list  . 
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B SPLINE  SURFACE-V  MULTIPLICITIES  - list  . 
b“spline  surface-v~rational  - logical  . 
b“sPLINE“SURFACE-v”unIFORM  » logical  . 

B“sPLINE“sURf'ACE-V_UPPER  » integar  . 

B~SPLINE  SURFACE-WEIGHTS  » list  . 

B^SPLINEIsURFACI  » "(" 

B SPLINE  SURFACE -CONTROL  POINTS  " , " 

[”b  SPLINE_SURFACE-F0RM  number  ] 

B_SPLINE  SURrACE-U_DEGR£E 

B spline'surface-u  knots 
b“splineIsurface-u”multiplicities  " , '• 

B SPLINE_SURFACE-U  RATIONAL  " , " 

B SPLINE_SURFACE-U"UNIF0RM  " , " 

B~SPLINE  SURFACE -U”UPPER  " , " 

B spline“surface-v"degree 
b”spline”surface-v"knots 
b'SPLINE-SURFACE-V-MULTIPLICITIES  •• , " 

B SPLINE-SURFACE-V'rATIONAL 

b'spline  surface -v"un I form 

b'sPLINE-SURFACE-V-UPPER 
["b  SPLINE_SURFACE-WEIGHTS  ] 

CARTESIAN  POINT  - CARTESIAN  THR£E_COORDINATE 
1 CARTES IAnItWO_COORDINATE  . 

CARTESIAN  THREE  COORDINATE-X_COORDINATE  - real  . 
cartesian”three”coordinate-y_coordinate  » real  . 

CARTES IAN_THREEIcOORDINATE-Z  COORDINATE  » real  . 
cartes IAM_THRBE_C00RDINATE 

CARTESIAN  THREE  COORDINATE-X  COORDINATE 
CARTES IAN”THREE2C0ORDINATE-y“C0ORDINATE 
CARTES I AN~THREE_COORD INATE - Z “cOORD I NATE 

")"  . 

CARTESIAN  TWO  COORDINATE-X  COORDINATE  - real  . 

CARTES I AN”tW0~C00RDINATE-y“C00RDINATE  « real  . 

CARTES IAN~TWO  COORDINATE 

CARTESIAN_TWO  COORDINATE-X_COORDINATE  " , ” 
CARTES IAN_TWO“COORDINATE- Y_COORDINATE 
" ) " . ” ~ 

CIRCLE-POSITION - entity  reference  \ AXIS2_PLACEMENT  . 

CIRCLE-RADIUS  » real  . 

CIRCLE  - •*(" 

CIRCLE- POSITION " , " 

CIRCLE-RADIUS 

. 

CLOSED  SHELL-CSHELL  BOUNDARY  » list  . 

CLOSED^SHELL  » " 

CLOSED_SHELL-CSHELL_BOUNDARY 
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COMPOSITE  CURVE-CLOSED  CURVE  » logical  . 

COMPOS ite“curve-param  ^GE  » list  . 

COMPOSITE'cURVE-SEGMENTS  » list  . 

COMPOS ITE“cURVE-S ELF  INTERSECT  « logical  . 

COMPOSITE“cURVE-SENSES  - list  . 

COMPOS ite'curve-transitions  » list  . 

COMPOS  ITE"cURVE  - "C* 

COMPOSITE  CURVE -CLOSED  CURVE  " 

C COMPOSlfE_CURVE-PARAM  RANGE  ] " , " 

COMPOSITE  CURVE -SEGMENTS 

COMPOS ite“curve-self_intersect  " , " 

COMPOS ite”curve-senses 
COMPOS ITE”cURVE -TRANS ITIONS 

COMPOSITE  CURVE  ON_SURFACE-BASIS  SURFACE  - entity_ref erenca  | SURFACE  . 
COMPOS ITEIcURVE'ON  SURFACE-CLOSED  CURVE  • logical  . 

COMPOS ITE_CURVElON”sURFACE-SEGMENfs  ■ list  . 

COMPOS I TE_CURVE  ON~SURFACE-SENSES  - list  . 

COMPOSITE  CURVE”0N“sURFACE-TRANSITI0NS  - list  . 

COMPOS ite"curve”on"surface  « "(« 

COMPOSITE  CURVE_ON_SURFACE-BASIS_SURFACE  " , 
COMPOS ite^curve  on  surface-closed  curve 
COMPOSITE  CURVE”0N"sURFACE- SEGMENTS  " , " 

composite“curve~on_surface-senses 
COMPOS ite”curve"on  surface-transitions 

conic  - PARABOLA 
HYPERBOLA 
ELLIPSE 
CIRCLE  . 

CONICAL  SURFACE- POSITION » antity_raf erenca  1 AXIS2  PLACEMENT  . 

conical“surface-radius  - real  . 
conical“surface-semi_angle  - real  . 

CONI CAL'SURF ACE  » " ( " 

CONICAL  SURFACE- POSITION 

conical”surface-raoius  " , " 
conical”surface-semi  angle 

CURVE  » OFFSET  CURVE 

CURVE  ON  SURFACE 
BOUNDED  CURVE 
CONIC 
LINE  . 

CURVE_BOUNDED_SURFACE-BASIS  SURFACE  » entity_reference  | SURFACE  . 
CURVE_BOUNDED_SURFACE-BOUNDARIES  » list  . 

CURVE  BOUNDED_SURFACE-OUTER  PRESENT  » logical  . 
curve" BOUNDED  SURFACE  » 
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CURVE_BOUNDED_SURJACE-BASIS  SURFACE 
CURVE_BOUNDED_SURFACE-BOUNDARIES  ^ , " 
CURVE~BOUNDED~SURF ACE -OUTER  PRESENT 

CURVE  LOGICAL  STRUCTURE -CURVE  ELEMENT  - logical  . 
CLTIVE“L0GICAlIsTRUCTURE-FLAG  - logical  . 

CURVE”LOCICAL_STRacrCRE  ■ "(" 

“*  ” CURVE  LOGICAL  STRUCTURE -CURVE_ELEMENT  " , " 

CURVE'LOG I CAL“s TRUCTURE - FLAG 

CURVE  ON_SURFACE  » COMPOSITE  CURVE_ON  SURFACE 

I NTERS ECT I0N_CURVE” 

SURFACE_CURVE 
PCURVE  . 

CYLINDRICAL_SURFACE-POSITION « entity  reference  | AXIS2  PLACEMENT  . 

CYLINDRICAL  SURFACE-RADIUS  « real  . 

CYLINDRICAL^SURFACE  « " { " 

CYLINDRICAL  SURFACE-POSITION " , " 

CYLINDRICAL-SURFACE-RADIUS 

D2  OFFSET  CURVE-BASIS  CURVE  - integer  . 

D2-OFFSET-CURVE-DISTANCE  « real  . 

D2  OFFSET-CURVE-SELF  INTERSECT  • logical  . 

D2-OFFS1T-CDRVE  - " 

D2_OFFSET_CURVE-BASIS  CURVE 
D2_OFFSET_CURVE-OISTANCE  " , " 

D2  OFFSET  CURVE-SELF  INTERSECT 


D3_0FFSET  CURVE-BASIS  CURVE  - entity  reference  ] CURVE  . 

D3  OFFSETIcURVE-DISTANCE  - real  . 

D3-OFFSET  CURVE-REF_DIRECTION  - entity  reference  | DIRECTION  . 
D3-0FFSET-CURVE-SELF  INTERSECT  » entity  reference  | DIRECTION  . 
D3-OFPSET-CDRVE  » "(" 

D3  OFFSET  CURVE-BASIS  CURVE  " , " 
D3-OFFSET-CURVE-DISTANCE  " , " 
D3-OFFSET-CURVE-REF  DIRECTION 
D3-OFFSET-CURVE-SELF  INTERSECT 

DIRECTION  - THREE_SPACE_DIRECTION 
I TWO_SPACE_DIRECTION  . 

EDGE-EDGE_CURVE  - entity_reference  | CURVE_LOGICAL_STRUCTURE  . 
EDGE-EDGE_END  » entity_ref erence  1 VERTEX  . 

EDGE-EDGE-START  ■ entity  reference  | VERTEX  . 

EDGE  - 

[ EDGE-EDGE  CURVE  ] " , " 

EDGE-EDGE  END 
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EDGE-EDGE_START 

. 

EDGE  LOGICAL  STRUCTURE-EDGE_ELEMENT  » entity_raf erence  [ EDGE  . 
EDGE"L0GICAL“sTRUCTURE-FLAG  » logical  . 

edgb“logicxl_structure  - "C 

EDGE_LOGICAL  STRUCTURE -EDGE  ELEMENT  " , " 

E DGE_LOGI CAL”sTRUCTURE - flag" 

w ) w — ~ 

EDGE  LOOP-LOOP_EDGES  - list  . 

EDGE^LOOP  - 

E DGE_LOO P- LOO P_EDGES 

" ) •*  . " 

ELEMENT ARY_SURFACE  - TOROIDAL_SURFACE 

SPHERICAL  SURFACE 
CONICAL  SURFACE 
CYLINDRICAL  SURFACE 
PLANE  . 

ELLIPSE-POSITION ■ entity  reference  1 AXIS2_PLACEMENT  . 

ELLIPSE-SEMI_AXIS_1  - real  7 
ELLIPSE-SEMI_AXIS_2  - real  . 

ELLIPSE-POSITION 

ELLIPSE-SEMI  AXIS  1 

ellipse-semi“axis"2 

FACE-BOUNDS  - list  . 

FACE-FACE_SURFACE  » antity_ref erence  | SURFACE  LOGICAL  STRUCTURE  . 
FACE-OUTER_BOUND  - entity  reference  | LOOP_LOGICAL_STRUCTURE  . 

PACE  » "(" 

FACE-BOUNDS 
[ FACE -FACE  SURFACE  ] 

[ FACE-OUTER  BOUND  ] 

FACE  LOGICAL_STRUCTURE-FACE  ELEMENT  - entity_ref erence  | FACE  . 
FACE“L0GICAL  STRUCTURE- flag”-  logical  . 

face"logicalIstrxjctdre  - 

FACE_LOGICAL_STRUCTURE-FACE  ELEMENT  " , " 
FACE  LOGICAL  STRUCTURE- FLAG 

GEOMETRY  - SURFACE 
CURVE 

TRANSFORMATION 
AXIS  PLACEMENT 
VECTOR 
POINT  . 
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HYPERBOLA-POSITION ■ entity  reference  | AXIS2  PtACEMZNT  . 

HYPERBOLA-SEMI_AXIS  « real  . 

HYPERBOLA-SEMI  IMAG  AXIS  « real  . 

HYPERBOLA  - •»(" 

HYPERBOLA-POSITION 

HYPERBOLA-SEMI_AXIS 
HYPERBOLA-SEMI  IMAG  AXIS 

rNTERSECTION_CURVE-BASIS  CURVE  » entity  reference  | CURVE  . 
INTERSECTION  CURVE-MASTER  REPRESENTATION  - "string"  . . 

INTERSECTION“curve-PCURVE“si  » entity  reference  PCURVE  . 

INTERSECTION”cURVE-PCURVE“S2  - entity'reference  PCURVE  . 

INTERSECTION  CURVE -SELE_INTERSECT  « logical  . 
INTERSECTION”cURVE-SURFACE_S1  - entity  reference  I SURFACE  . 
INTERSECTION'’curve-SURFACE  S2  - entity^reference  1 SURFACE  . 
INTERSECTION“cURVE  « "(" 

INTERSECTION  CURVE-BASIS  CURVE  "," 

[ INTERSECTION  CURVE-MASTER  REPRESENTATION  ] 

[ intersection“curve-pcurve“si  ] 

[ intersection”curve-pcurve“s2  ] 

INTERSECTION  CURVE-SELF_INTERSECT  . 

C INTERSECTION_CURVE-SURFACE  SI  ] 

[ INTERSECTION  CURVE-SURFACEIS2  ] 


LINE-DIR  ■ entity  reference  DIRECTION  . 

LINE-PNT  » entity-reference  CARTESIAN  POINT  . 

LINE  - "(" 

LINE-DIR 

LINE-PNT 

If  ) H 

LINE  SEGMENT-FIRST_POINT  » entity  reference  | CARTES I AN_POINT  . 
LINE~SEGMENT-LAST  POINT  ■ entity _reference  | CARTES I AN_POINT  . 
LINE  SEGMENT  - 

LINE_SEGMENT-FIRST_POINT 
LINE  SEGMENT-LAST  POINT 


LOOP  - POLY  LOOP 
edge“loop 
VERTEX_LOOP  . 

LOOP_LOGICAL  STRUCTURE -FLAG  « logical  . 

LOOP  LOGICAL-STRUCTURE-LOOP  ELEMENT  « entity_reference  | LOOP  . 
LOOP-LOGICAL“STRDCTUR£  - " ( • 

LOOP  LOGICAL_STRUCTURE-FLAG 
LOOp-LOGICAL  STRUCTURE- LOO P_EL£MENT 

OFFSET  CURVE  « D3  OFFSET_CURVE 

1 D2-OFFSET_CURVE  . 
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OFFSET  SUHFACE-BASIS  SURFACE  - «ntity_r«f«r«nc«  | SURFACE  . 
OFFSET“sURFACE-DISTAKCE  - real  . 
OFFSET“sURFACE-SELF_INTERSECT  » logical  . 

OFFSET  SURFACE  » "(" 

0FFSET_SURFACE-BASIS_SURFACE 
OFFSET  SURFACE-DISTANCE 

offset”surface-self_intersect 

"" 

open  shell-shell  boundary  - list  . 

OPEN”sHELL  » 

open_shell-shell_boundary 

H ) » ^ “ 

parabola-focal_dist  » real  . 

parabola-position - entity  reference  | AXIS2_PLACEMENT  . 

parabola  - 

PARABOLA-FOCAL  DIST  " , " 

PARABOLA- POS ITION 

")"  . 

PATH-OPEN  EDGE_LIST  - list  . 

PATH  » "(" 

PATH-OPEN_EDGE_LIST 

PCURVE-BASIS_CURVE  ■ entity__ref erence  | CURVE  . 
PCURVE-BASIS”SURFACE  » entity  reference  | SURFACE  . 

PCURVE  » 

PCURVE-BASIS  CURVE 
PCURVE- BAS IS“SURFACE 

PLANE-POSITION - entity  reference  | AXIS2  PLACEMENT  . 

PIANE  • "(" 

PLANE-POSITION 

")"  . 

POINT  » POINT  ON  SURFACE 

point”on”curve 

CARTES IAN_POINT  . 

POINT  ON  CURVE-BASIS  CURVE  » entity  reference  1 CURVE  . 

point"on"curve-point”parameter  » real  . 

POINT  OM”cURVE 

POINT  ON_CURVE-BASIS_CURVE 
POINT”oN  CURVE- point  PARAMETER 

POINT  ON  STOFACE-BASIS_SURFACE  » entity  reference  | SURFACE  . 
POINT"0N”sURFACE-POINT  parameter  1 - real  .• 

POINT  ON  SURFACE- P0INT“PARAMETER”2  - real  . 
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POINT_ON  SURFACE  - " ( " 

POINT_ON_SURFACE-BASIS  SURFACE  ” , " 

POINT_ON  SURFACE -POrNT*"PARAMETEH  1 
POINT  ON”SURFACE-POINT”PARAJffiTER”2 

POLY  LOOP-POLYGON  - list  . 

POLY“LOOP  « "(" 

PO LY_LOO P- PO LYGON 

H ) « 

RECTANGULAR  COMPOS ITE_SURFACE-N  U » intsgsr  . 

RECTANGULAR”cOMPOSITE  SURrACE-N”v  * intsgsr  . 

r£ctangular“composite“surface-surfaces  » list  . 
rectanguiar_composite”surface-u_senses  - list  . 
rectangular  compos ite”surface-v  senses  » list  . 

REeTANGULAR“cOICPOSITE“sURFAai  «”'•(" 

RECTANGULAR_COMPOSITE  SURFACE-N_U  " , " 
RECTANGULAR  COMPOS ITE“sURFACE-N  V 

rectangular”compositi  surface-surfaces  " , " 
rectangular3composite”surface-u_senses  ” 
rectangular_composite”surface-v_senses 
" ) " . ” ~ 

rectangular  TRIMM1D_SURFACE-BASIS_SURFACE  - int«g«r  . 
rectangular”trimig:d_surface-umax  » rsal  . 
rectangular  trimmed  SURFACE-UMIN  - real  . 
rectangular'triioed'surface-vmax  » real  . 

RECTANGULAR  TRIJ^fED-SURFACE-VMIN  - real  . 

RECTANGULAR^TRSflffiD'SDRFACl  « "(" 

RECTANGULAR_TRIKMED  SURFACE-BASIS_SURFACE  " , " 
RECTANGULAR  TRIf@fED“SURFACE-UMAX 
RECTANGU1AR“'TRI!0<ED“sURFACE-UMIN  " , " 

rectangular"trikmed”surface-vmax  " , " 

RECTANGUlAR_TRII@IlD_SURrACE-VMIN 

" ) " . "*  ” 

REGION-OUTER_REGION_BOUNDA^Y  - entity  reference  | SHELL_L0GICAL_STRUCTL^E  . 
REGION-REGION_BQUNDARIES  » list  . 

REGION  » "(" 

[ REGION-OUTER  REGION  BOUNDARY  ] 

REGION-REGION  loUNDARIES 

SHELL  » CLOSED  SHELL 
OPEN  SHILL 
WIR£-SH1LL 
VERTfx_SHELL  . 

SELECT  FACE  OR  SUBFACE  « 

FACE 

SUBFACl  . 
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SHELL  LOGICAL_STRUCTUR£-FLAG  » logical  . 

SHELL”lOGICAL_STRUCTURE-SHELL  ELEMENT  - entity_ref erence  I SHELL  . 
SHELL_LOGICAi  STRUCTURE  » 

SHELL_LOGICAL_STRUCTURE-FLAG  " , " 
SHELL_LOGICAL_STRUCTURE-SHELL  ELEMENT 


SPHERICAL  SURFACE-POSITION « entity  reference  ( AXIS2  PLACEMENT  . 

spherical“surface-radius  » real  . 

SPHERICAL“sUREACE  - 

spherical  surface- position 

S PHERI CAL“sURFACE-RADIUS 


SUBFACE -BOUNDS  - list  . 

SUBFACE-0UTER_B0UND  « entity_ref erence  | LOOP_LOGICAL_STRUCTURE  . 
SUBFACE-TRIMMING  - entity  reference  | SELECT_FACE_OR  SUBFACE  . 

SUBPACE  - 

SUBFACE-BOUNDS 
SUBFACE-OUTER  BOUND  " , " 

subface-trimmIng 
")"  . 

SURFACE  - RECTANGUIAR_COMPOSITE  SURFACE 
OFFSET  SURFACE 
BOUNDED  SURFACE 
• SWEPT_SURFACE 

ELEMENTARY^SURFACE  . 

SURFACE  CURVE-CURVE  1 ■ entity_ref erence  | CURVE  . 

SURFACE^CURVE-MASTER  « "."string"."  . 

SURFACE_CURVE-PCURVE  SI  ■ entity  reference  PCURVE  . 

SURFACE  CURVE-SURFACE  1 « entity”ref erence  SURFACE  . 

SURPACEIcURVE  - " 

SURFACE  CURVE-CURVE_1  "," 

[ SURFACE_CURVE-MASTER  ] "," 

[ SURFACE  CURVE -PCURVE_S1  ] "," 

SURFACE_COTVE-SURFACE  1 
")  " . 

SURFACE_LOGICAL  STRUCTURE- FLAG  - logical  . 

SURFACE  LOGICAL”sTRUCTURE-SURFACE_ELEMENT  » logical  . 

SURPACE'LOGICAL  structure  ■ "(" 

SURFACE_LOGICAL  STRUCTURE- FLAG  "," 

SURFACE  LOGICAL”sTRUCTURE-SURFACE  ELEMENT 


SURFACE_OF_LINEAR_EXTRUSION-AXIS  » entity  reference  | DIRECTION  . 

SURFACE  OF_LINEAR_EXTRUSION-EXTRUDED  CURVE  ■ entity_reference  j CURVE  . 
surface”© P_LINEAR_EXTRUS ION  » " 

SURFACE  OP  LINEAR  EXTRUSION- AXIS 
SURrACE”0P”LINEAR”EXTRUSI0N-EXTRUDED  CURVE 
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SURFACE_OF_REVOLUTION-AXIS  » entity_ref arenc#  | DIRECTIOH  . 
StrRFACE_OF_REVOLUTIOM-AXIS  POINT  » entity  reference  | CARTESIAN  POINT  . 
SURFACE_OF  REVOLUTION-REVOLVED  CURVE  « entity  reference  I CURVE". 
SURFAC:Z_OP_REVOLDTIOH  « " 

SURFACE_OF_REVOLUTION-AXIS  " , " 

SURFACE  OF^REVOLUTION-AXIS_POINT  " , 

surface“of”revolution-revolved  curve 

SWEPT  SURFACE  - SURFACE_OF  LINEAR  EXTRUSION 
I SURFACE_OF(^REVOLUflON  . 

THREE_SPACE  DIRECTION-X  - real  . 

THREE  SPACEIdIRECTION-Y  - real  . 

THREE'sPACE  DIRECTION-2  - real  . 

THREE  SPACE~DIRECnOM  « "(" 

THREE  SPACE  DIRECTION-X 
three's PACE”DIRECTI0N-Y 

three”space2direction-2 

« ) It  ^ ~ 

TOPOLOGY  - REGION 
SHELL 
SUBFACE 
FACE 
LOOP 
PATH 
EDGE 

VERTEX  . 

TOROIDAL  SURFACE-MAJOR  RADIUS  - real  . 

toroidal“surface-minor"radius  « real  . 

TOROIDAL  SURFACE-POSITION » entity  reference  | AXIS2  PLACEMENT  . 

T0R0IDAL~SDREACE  - 

TOROIDAL  SURFACE-MAJOR  RADIUS  " , " 

toroidal"surface-minor"radius  " , •• 

TORO I DAL^SURFACE - PCS  I TION 


TRANSFORMATION' 

TRANSFORMATION 

TRANSFORMATION 

TRANSFORMATION' 

TRANSFORMATION 

TRANSFORMATION 


•AXISl  ■ entity_reference 
•AXIS2  ■ entity^reference 
•AXIS3  • entity'reference 
-LOCAL_ORIGIN 
■SCALE  • real 


DIRECTION  . 

THREE  SPACE  DIRECTION 

three"space~direction 


'entity_reference  T CARTES  I AN_POINT 


[ TRANS FORMATION- AXISl  ] 

[ TRANSFORMATION-AXIS2  ] 

[ TRANS FORMATION- AXIS 3 ] 

[ TRANS FORMATION- LOCAL  ORIGIN  ] 

[ transformation-scale"] 
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TRIMMI:D_CURVE-BASIS  CURVI  = integer  . 

TRIMMED  CURVE -PARAMETER  1 » real  . 

TRIMMED~CURVE-PARAMETER“2  - real  . 

TRIMMED~CURVE-POINT_l  ■”antity_ref erence  CARTES IAN_POINT  . 
TRIMMED  CURVE-P0INT”2  » entity  reference  CARTESIAN  POINT  . 
TRIMMED“curve-SENSE”»  logical  T 
TRIM!1ED_CURVB  » "(•* 

TRIMMED_CURVE-BASIS  CURVE  ^ " 

[ TRIMMED_CURVE- PARAMETER  1 ] 

[ TRIMMED  CURVE -PARAMZTER“2  ] 

[ TRIMMED“cURVE- POINT  1 ] 

C trimmzd”curve-point"2  ] 

TRIMMED  CURVE-SENSE 


TWO  SPACE  DIRECTION-X  - real  . 

TWo“sPACE”DIRECTION-Y  - real  . 

TWO  SPACE~DIRZCnOH  - 

TWO  SPACE  DIRECTION-X  " , " 

two”space”direction-y 

vector  - vector  with_magnitude 
I direction  . 

vector  WITH_MAGNITUDE-MACNITUDE  - real  . 

VECTOR-WITH  MAGNITUDE-ORIENTATION  - entity_ref erence  1 DIRECTION  . 
VECTOR“wITH“MAGNITUDE  » "(" 

VECTOR  WITH  MAGNITUDE-MAGNITUDE  " , " 

vector”with”magnitude-orientation 

" ) **  . ~ ” 

VERTEX-VERTEX  POINT  - entity  reference  | POINT  . 

VERTEX  - "C*  ” 

[ VERTEX- VERTEX_POINT  ] 

" ) " 

VERTEX  LOOP-LOOP  VERTEX  ■ entity  reference  | VERTEX  . 

VERTEX“lOOP  - 

VERTEX_LOO P- LOO P_VERTEX 

VERTEX_SHELL-VERTEX  SHELL  BOUNDARY  « entity  reference  | VERTEX_LOOP  . 
VERTEX  SHELL  »••(*•” 

VERTEX  SHELL-VERTEX_SHELL  BOUNDARY 

WIRE  SHELL-WIRE_SHELL  BOUNDARY  - list  . 

WIRE  SHELL  - 

WIRE_SHELL-WIRE_SHELL  BOUNDARY 

ENTITY_DEr  » { 
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AXISl_PtJiCEMZNTalias  AXISl  PLACEMENT 
AXIS2_PLACEMENTaiias  AXISZ^PLACEMENT 
BEZIER  CURVEalias  BE2IER_CURVE 
BE2IER”sUR5ACEalias  BEZIER_SURFACE 
B_SPLINE  CURVEalias  B SPLINE  CURVE 
B SPLINE_SURFACEalias“B_SPLINE  SURFACE 

CARTESIAN_THR£E_COORDINATEalia5  CARTES I AN_THR£E  COORDINATE 
CARTESIAN  TWO  COORDINATEalias  CARTESIAN  TWO  COO^INATE 
CIRCLEalias  CIRCLE 
CLOSED_SHELLalias  CLOSED_SHELL 
COMPOS ITE_CURVEalias  COMPOS ITE^CURVE 

COMPOS ITE“cURVE_ON_SURFACEal iai  COMPOS ITE_CURVE_ON_SURFACE 
CONICAL_SURFACEalias  CONICAL_SURFACE 
CURVE_BOUNDED_SURFACEal ias  CURVE_BOUNDED_SURFACE 
CURVE~LOGICAL  STRUCTUREalias  CUR^  LOGICAL  STRUCTURE 
CYLINDRICAL_SURFACEal ias  CYLINDRICAL_SURFACE 
D2  OFFSET  CURVEalias  D2  OFFSET  CURVE 
D3"OFFSET”cURVEalias  D3“0FFSET”cURVE 
EDGEalias”EDGE 

EDGE_LOGICAL  STRUCTUREalias  EDGE  LOGICAL  STRUCTURE 
EDGE_LOOPalias  EDGE_LOOP 
ELLIPSEalias  ELLIPSE 
FACEalias  FACE 

FACE  LOGICAL_STRUCTUREalias  FACE_LOGICAL  STRUCTURE 
HYPERBOLAalias  HYPERBOLA 

INTERSECTION  CURVEalias  INTERSECT I ON_CURVE 
LINEalias  LINE 

LINE_SEGMENTalias  LINE  SEGMENT 

LOOP”lOGICAL  STRUCTUREalias  LOOP_LOGICAL  STRUCTURE 

OFFSET  SURFACEalias  OFFSET_SURFACE 

OPEN_SHELLalias  OPEN  SHELL 

PARABOLAalias  PARABOLA 

PATHalias  PATH 

PCURVEalias  PCURVE 

PLANEalias  PLANE 

POINT  ON  CURVEalias  POINT  ON_CURVE 
POINT~ON"SURFACEalias  POINT  ON  SURFACE 
POLY  LOOPalias  POLY  LOOP 

RECTANGULAR  COMPOSITE  SURFACEalias  RECTANGULAR_COMPOSITE  SURFACE 
R£CTANGULAR“TRIMMED  SURFACEalias  RECTANGULAR_TRIMMED_SURFACE 
REGIONS lias”REGION 

SHELL  LOGICAL  STRUCTUREalias  SHELL  LOGICAL_STRUCTUR£ 

SPHERICAL  SURFACEalias  SPHERICAL  SURFACE 

SUBFACEallas  SUBFACE 

SURFACE  CURVEalias  SURFACE  CURVE 

SURFACE”LOGICAL_STRUCTUREaTias  SURFACE  LOGICAL  STRUCTURE 
SURFACE“OF_LINEAR_EXTRUSIONalias  SURFACE  OF  LINEAR_EXTRUSION 
SURFACE  OP_REVOLUTIONalias  SURFACE_OP_R£VOLUTIOM 
THREE  SPACE  DIRECTIONalias  THREE  SPACE_DIRECTION 
TOROIDAL_SU^ACEal ias  TOROIDAL_SURFACE 
TRANSFORMATIONalias  TRANSFORMATION 
TRIMMED_CURVEalias  TRIMMED_CURVE 
TWO  SPACE  DIRECTIONalias  TWO  SPACE  DIRECTION 
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VICTOR  WITH  MAGNITUDEaiias  VICTOR_WITH  MAGNITUDE 
VIRTEXalias'viRTEX 
VERTEX_LOOPalias  VERTEX_LOOP 
VERTEX_SHELLalias  VERTEX  SHELL 
WIRE  SHELLalias  WIRE  SHELL 


AXISl  PLACEMENTaliaa  « "AXISl  PLACEMENT" 
AXIS2”PLACEMENTalias  « "AXIS2”PLACEMENT" 
BEZIER  CURVEalias  - "BEZIER  CURVE"  I "CVZ" 


"AXl" 

"AX2" 


BEZIER  SURFACEalias  « "BEZIER  SURFACE"  "SFZ"  . 

B SPLINE  CURVEalias  - "B_SPLINE_CURVE"  "CVB"  . 

B“SPLINE“sURFACEalias  « "B  SPLINE_SURFACE"  | "SFB"  . 

CARTESIAN  THREE  COORDINATEalias  - "CARTES I AN_THREE  COORDINATE"  | "PT3"  , 
CARTESIAN”TWO_COORDINATEalias  » "CARTESIAN  TWO  COORDINATE"  | "PT2"  . 
CIRCLEalias  « "CIRCLE"  I "Cl"  . 

CLOSED_SHELLalias  » "CLOSED  SHELL"  | "SHC"  . 

COMPOSITE  CURVEalias  « "COMPOSITE  CURVE"  | "CVC"  . 

COMPOS ITE“cURVE  on  SURFACEalias  -“"COMPOSITE_CURVE_OM  SURFACE"  | "CVCS" 
CONICAL  SURFACEalias  « "CONICAL_SURFACE"  | "SFCN"  . 
CURVE_BOUNDED_SURFACEalias  « "CURVE  BOUNDED  SURFACE"  | "SFCD"  . 
CLTlVE_LOGICAL  STRUCTUREalias  - "CUR^  LOGICAL_STRUCTURE"  | "CVD"  . 
CYLINDRICAL  SURFACEalias  - "CYLINDRICAL  SURFACE"  I "SFCYL"  . 


"CVF2" 

"CVF3" 


D2  OFFSET  CURVEalias  - "D2  OFFSET  CURVE" 
D3”0FFSET”cURVEalias  - "D3“0FFSET”cURVE" 

EDGEalias  - "EDGE"  | "ED"  7 
EDGE  LOGICAL_STRUCTUREalias  - "EDGE_LOGICAL_STRUCTURE" 
EDGE_LOOPalias  » "EDGE  LOOP"  | "LPE"  . 

ELLIPSEalias  - "ELLIPSE"  1 "EL"  . 

FACEalias  » "FACE"  1 "FC"  . 

FACE  LOGICAL  STRUCTUREalias  - "FACE  LOGICAL_STRUCTURE" 
HYPERBOLAalias  « "HYPERBOLA"  | "HP"". 

INTERSECTION  CURVEalias  « "INTERSECTION  CURVE"  I "CVX" 


•EGD’ 


"FCD" 


LINEalias  » "LINE"  I "LN"  . 

LINE  SEGMENTalias  - "LINE  SEGMENT"  | "LS"  . 

LOOP"LOGICAL_STRUCTUR£aliaa  » "LOOP  LOGICAL  STRUCTURE"  | "LPD"  . 

OFFSET  SURFACEalias  - "OFFSET  SURFACE"  1 "SFF"  . 

OPEN  SHELLalias  - "OPEN  SHELL"  | "SHO"  . 

PARABOLAalias  » "PARABOLA"  | "PB"  . 

PATHalias  - "PATH"  | "PA"  . 

PCURVEalias  - "PCURVE"  | "CVP"  . 

PLANEalias  - "PLANE"  I "PL"  . 

POINT  ON  CURVEalias  - "POINT  ON  CURVE"  | "PTC"  . 

POINT"ON"sURFACEalias  « "POINT  ON  SURFACE"  1 "PTS"  . 

POLY  LOOPalias  - "POLY  LOOP"  |""LPP"  . 

RECTANGULAR  COMPOSITE  SURFACEalias  « "RECTANGULAR  COMPOS ITE_SURFACE"  | "SFRC 
RECTANGULAR"TRIMMED  SURFACEalias  - "RECTANGULAR  TRIMMED  SURFACE"  | "SFR"  . 
REGIONalias"-  "REGION"  | "RG"  . 

SHELL  LOGICAL  STRUCTUREalias  - "SHELL_LOGICAL  STRUCTURE"  | "SHD"  . 
SPHERlCAL_SURFACEalias  - "SPHERICAL  SURFACE"  J "SFSP"  . 

SUBFACEalias  - "SUBFACE"  | "FCS"  . 

SURFACE  CURVEalias  - "SURFACE_CURVE"  | "CVS"  . 

SURFACE"loGICAL  STRUCTUREalias  « "SURFACE_LOGICAL_STRUCTUR£"  | "SFD"  . 
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SURFACE  OF  LINEAR  EXTRUSIONalias  - "SURFACE  OF  LINEAR  EXTRUSION"  | 
SURFACE“OF~REVOLUflONaiias  » "SURFACE  OF  REVOLUTION"  T "SFRV"  . 
THREE  SPACE_DIR£CTIONalias  - "THREE  SPACE  DIRECTION"  "DIP"  . 
TOROIDAL  SURFACEalias  - "TOROIDAL  SURFACE"  | "SFT"  . 

TRANS FORMATIONa lias  « "TRANSFORMATION"  | "TM"  . 

TRIMMED_CURVEalias  - "TRIMMED  CURVE"  | "CVT"  . 

TWO  SPACE  DIRECTIONalias  » "TWO  SPACE  DIRECTION"  | "DI2"  . 
VECfOR_WlfH_MAGNITUDEalias  - "VECTOR  WITH_MAGNITUDE"  | "VCM"  . 
VERTEXalias  - "VERTEX"  | "VX"  . 

VERTEX  LOOPalias  « "VERTEX_LOOP"  | "LPV"  . 

VERTEX~SHELLalias  - "VERTEX_SHELL"  | "SHV"  . 

WIRE_SHELLalias  » "WIRE_SHELL"  1 "SHW"  . 

ENTITY_OCCURRENCE  - •ntity_identif ier  ENTITY_DEF  ";"  . 
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APPENDIX  D - PHYSICAL  EXCHANGE  MEDIUM  FORMATS 


D.O  PHYSICAL  EXCHANGE  MEDIUM  FORMATS 


0.1  MAGNETIC  TAPE 

When  a STEP  file  is  to  be  transported  via  magnetic  tape,  the  magnetic  tape 
should  have  the  following  characteristics: 

0 STANDARD 
0 UNLABELED 
0 9 TRACK 

0 1600  BPI 

0 PHYSICAL  BLOCKSIZE  - 800  BYTES 
0 1/2-INCH  TAPE 

0 DATA  ENCODING  ACCORDING  TO  ISO  6937  (See  Appendix  B for  more 
detail ) . 

The  above  characteristics  are  in  accord  with  ISO  3788  "Information  Processing 
Information  Interchange  Via  Magnetic  Tape". 

D.2  TELECOMMUNICATION  FORMAT 

To  be  determined. 
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CHAPTER  1 - INTRODUCTION 


1.0  INTRODUCTION 

This  document  identifies  the  process  through  which  Product  Data  entities 
defined  in  EXPRESS  are  mapped  to  the  physical  file  format  of  PDES/STEP.  It  is 
assumed  that  the  audience  of  this  document  is  familiar  with  the  EXPRESS 
language  (refer  to  STEP  Document  4.1.1,  The  Use  Of  Formal  Language)  and  the 
PDES/STEP  exchange  format  (refer  to  STEP  Document  4.2.1,  The  STEP  File 
Structure) . 

This  document  presents  the  simpler  concept  of  data  type  mapping  first  and  then 
discusses  the  more  complex  concept  of  entity  mapping.  Mapping  is  performed 
strictly  from  EXPRESS  to  the  physical  file  structure,  specifically  to  the  Data 
section  of  the  exchange  format.  Therefore,  the  headings  used  throughout  this 
document  utilize  the  same  terms  used  within  STEP  Document  4.1.1,  The  EXPRESS 
User  Guide.  As  a convenience  to  the  reader  of  this  document,  EXPRESS 
constructs  are  written  in  bold  upper  case  letters,  while  the  file  structure 
constructs  are  written  in  bold,  lower  case,  italicized  letters. 

The  EXPRESS  language  is  an  extremely  powerful  data  modeling  language  that 
contains  declarative  statements,  executable  statements,  and  algorithms.  For 
the  purposes  of  exchange,  only  the  declarative  statements  are  actually  mapped 
to  the  exchange  format.  The  executable  statements  and  algorithms  of  EXPRESS 
are  used  to  clarify  and  refine  the  definition  of  and  to  impose  constraints  upon 
the  attributes  of  Product  Data  entities.  The  executable  statements  are  not 
mapped  to  the  exchange  format. 

Several  mapping  examples  have  been  provided  throughout  this  document.  Blank 
spaces  and  blank  lines  have  been  inserted  into  the  exchange  format  of  several 
examples  to  aid  readability.  The  reader  should  note  that  these  blank  spaces 
and  blank  lines  need  not  appear  in  an  actual  exchange  format  file. 
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CHAPTER  2 - MAPPING  FROM  EXPRESS  TO  PHYSICAL  FILE  STRUCTURE 


2.0  MAPPING  FROM  EXPRESS  TO  PHYSICAL  FILE  STRUCTURE 

Table  2-1  provides  a quick  reference  of  the  mappings  between  the  Conceptual 
Schema  and  the  Physical  File  Structure.  Specifically,  these  are  the  mappings 
from  the  elements  or  constructs  of  EXPRESS  onto  their  counterparts  in  the  DATA 
section  of  the  STEP  file  structure.  This  table  has  been  organized  in 
alphabetical  order  while  the  content  of  this  document  has  been  organized  in 
increasing  order  of  complexity.  A more  detailed  discussion  of  the  individual 
mappings  is  presented  in  chapters  3 and  4 of  this  document. 


2.1  QUICK  REFERENCE  MAPPING  TABLE 


Table  2-1  Conceptual  Schema  to  Physical  File  Structure  MaDoino 


EXPRESS  CONSTRUCTS 

DATA  SECTION  CONSTRUCTS 

ARRAY 

list 

DERIVED  ATTRIBUTE 

NO  INSTANTIATION 

ENTITY 

entity  or  embedded  entity 

ENTITY  AS  AHRIBUTE 

embedded  entity  or 
entity  reference 

ENTITY  AS  SUPERTYPES 

NO  INSTANTIATION 

ENUMERATION 

enumeration 

FUNCTION 

NO  INSTANTIATION 

INTEGER 

inteaer 

LIST 

list 

LOGICAL 

enumeration 

MAP 

NO  INSTANTIATION 

PROCEDURE 

NO  INSTANTIATION 

REAL 

real 

REMARKS 

NO  INSTANTIATION 

RULE 

NO  INSTANTIATION 

SCHEMA 

NO  INSTANTIATION 

SELECT 

NO  INSTANTIATION 

SET 

list 

STRING 

strina 

TYPE 

NO  INSTANTIATION 

WHERE  RULES 

NO  INSTANTIATION 

2-1 


A 


-J 


: v'-'i  J V'J-f'.il.. 


..auT'cai 


t.’.j  , 'i- 

) 


j,' 


• '■'.  I : ■ i.i 


,.  *4 


|>C, 


ri,  ttv;'.  ' ^to-t  %|,v9biVCTC;  (-^  sfdlt  ■ 

, ^r|^^  L>J16 

.••••'  .■  ■■  ..  MO  .■  Jnsf^isfs#  sHJ'  fno'^l 

m'  >.<  V .!  '■  :u-i,n  dIi^  '13‘*’''  -^vrt.t  lo  nof^D«2  V 

>■  . ,:’ni':V'’'’>  tii;  '»' h'w' ffcai 

*43Mri  pnUifnan^ 

■ ■.'  ."t  t vji.‘q,.n5  ' f >'’-cnrjT.s'ic  c'  zpnfqqm 


i.S 


M 


• f \- 


.,  '•  I ■ < c -' 

^ 


-•*1 1 





i ^ 

f.:. 


■ vr ^ "in 

'mi' 

~-  VT,  m- 

. . 


If- 7 t 

• - ■ > .A  ■ 


‘UM'. 


''■  , A j,T  ' I®  ^ 

, -'^1  *^,:>P:Tok^ 


wAi«» 

JM 


Viv,  '-'i.  i ‘ 


i i ^ ! 

■’ji. 


...Xi 

..^y^  yyk.^i2m,M 




m 


i 


p «— 


i 


■ ,.W 

,M'-' 


N280 


ISO  TC184/SC4/WG1  ANNEX  C (Normative)  September  1933 

(Document  4.2.2) 

CHAPTER  3 - DATA  TYPE  MAPPINGS 


3.0 

DATA  TYPE 

MAPPINGS 

3.1 

BASE  DATA 

TYPES 

3.1.1 

INTEGER 

The  EXPRESS  construct  of  INTEGER  will  map  syntactically  to  the  DATA  section 
as  an  integer  data  type.  Any  restrictions  on  the  domain  of  the  data  type 
will  be  validated  at  a level  higher  than  the  file  structure.  See  the  mapping 
example  in  Section  3.1.5. 


3.1.2  STRING 

The  EXPRESS  construct  of  STRING  will  map  syntactically  to  the  DATA  section  as 
a string  data  type.  Any  restrictions  on  the  domain  of  the  data  type  will 
be  validated  at  a level  higher  than  the  file  structure.  See  the  mapping 
example  in  Section  3.1.5. 


3.1.3  LOGICAL 

The  EXPRESS  construct  of  LOGICAL  will  map  syntactically  to  the  DATA  section 
as  an  enumeration  data  type.  See  the  mapping  example  in  Section  3.1.5. 

The  EXPRESS  construct  of  LOGICAL  is  treated  as  a predefined  enumerated  data 
type  with  the  values  of  .T.,  .F.,  .U.. 


3.1.4  REAL 

The  EXPRESS  construct  of  REAL  will  map  syntactically  to  the  DATA  section  as  a 
real  data  type.  Any  restrictions  on  the  domain  of  the  data  type  will  be 
validated  at  a higher  level  than  the  file  structure.  See  the  mapping  example 
in  Section  3.1.5. 
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3.1.5  MAPPING  EXAMPLE 
Entity  Definition  in  EXPRESS 


ENTITY  WIDGET; 
il:  INTEGER(2);  < 
i2:  INTEGER;  < 
si:  STRING(3);  < 
s2:  STRING;  < 
1 : LOGICAL;  < 
rl:  REAL(4);  < 
r2:  REAL;  < 

END  ENTITY; 


Sample  Entity  Occurrence  in  DATA  Section 
(312-WIDGET(99. 99999/ ABC' , 'ABCDEFG' , .T.  ,9.0, 1 .2345) ; 

A A A A A 

II  III 

(!)  © ® (X)(f) 

11  had  a value  of  99  in  this  entity  occurrence.  The  number  2 in 
parenthesis  indicates  the  number  of  decimal  digits  allowed  in  values  for 
this  attribute.  In  this  case,  the  value  falls  within  the  specified  range 
(-99.. 99)  for  this  attribute.  The  value  is  syntactically  and  semantically 
1 egal . 

12  had  a value  of  99999  in  this  entity  occurrence. 

@ si  had  a value  of  'ABC'  in  this  entity  occurrence.  This  value  falls  within 

the  range  (3  characters)  specified  for  this  attribute.  The  value  is 
syntactically  and  semantically  legal. 

(J)  s2  had  a value  of  'ABCDEFG'  in  this  entity  occurrence. 

1 had  a value  of  TRUE  in  this  entity  occurrence. 

(7)  rl  had  a value  of  9.0  in  this  entity  occurrence.  This  value  falls  within 
the  range  (4  decimal  digits  in  the  fractional  part  of  a number)  specified 
for  this  attribute.  The  value  is  syntactically  and  semantically  legal. 

@ r2  had  a value  of  1.2345  in  this  entity  occurrence. 
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3.2  LIST 

The  EXPRESS  construct  of  LIST  will  map  syntactically  to  the  DATA  section  as  a 
list  data  type.  If  a list  is  optional  and  does  not  exist,  it  is  treated 
as  a defaulted  field  in  the  DATA  section  (refer  to  Chapter  7 of  STEP  Document 
ANNEX  B Normative,  The  STEP  File  Structure).  If  the  list  is  empty,  it  will 
appear  in  the  DATA  section  as  an  open  parenthesis  immediately  followed  by  a 
close  parenthesis. 


3.2.1  MaoDino  Example 

Entity  Definition  In  EXPRESS 


ENTITY  WIDGET; 
attributel : 
attribute2: 
attributes: 
attribute4: 
END.ENTITY; 


LIST  [0  : #]  OF  INTEGER;  < (a) 

LIST  [1  : #]  OF  INTEGER;  < — • 

OPTIONAL  LIST  [1  : #]  OF  INTEGER;  <-• 
REAL; 


Sample  Entity  Occurrence  In  DATA  Section 


024 


WIDGET(  il,  LLUl,  > 2.56); 


attribute  3 did  not  exist 
in  this  occurrence. 


attribute  2 
elements  in 


contained  three 
this  occurrence. 


attribute  1 
list. 


was  an  empty 
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3.3  ARRAY 

The  EXPRESS  construct  of  ARRAY  will  map  syntactically  in  the  DATA  section  as 
a List  data  type.  The  restrictions  on  the  bounds  of  the  array  implied  in 
the  Conceptual  Schema  will  be  validated  at  a level  higher  than  that  of  the  file 
structure.  An  ARRAY  [i:j]  where  j > i has  j-i+1  elements. 


3.3.1  Mapping  Example 

Entity  Definition  In  EXPRESS 


ENTITY  WIDGET; 
attributel : 
attribute2: 
attributes: 
END.ENTITY; 


ARRAY  [-1  : 3]  OF  INTEGER;  < (a)  _ 

ARRAY  [1  : 5]  OF  OPTIONAL  INTEGER;  (b) 

ARRAY  [1  : 2]  OF  ARRAY  [1  : 3]  OF  INTEGER; 


Sample  Entity  Occurrence  In  DATA  Section 


(330  - WIDGETffl.2.3.4.51  , (1.2.3. .511  , ((1.2.31.(4.5.6111: 


@ ® © 


@ attributel  contained  the  following  values 

attributel  [-1]  - 1 
attributel  [0]  * 2 

attributel  [1]  - 3 

attributel  [1]  - 4 

attributel  [1]  » 5 

attributes  contained  the  following  values.  The 
meaning  of  a missing  value  must  be  defined  in  the 
conceptual  schema  document. 

attributes  [1]  » 1 
attributes  [2]  » 2 
attributes  [3]  ■ 3 
attributes  [4]  » MISSING 
attributes  [5]  • 5 
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Mapping  Example  (continued) 

attributes  contained  the  following  values 

attributes  [1,1]  ■ 1 
attributes  [1,2]  » 2 
attributes  [1,3]  • S 
attributes  [2,1]  ■ 4 
attributes  [2,2]  ■ 5 
attributes  [2,S]  » 6 
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3.4  SET 

The  EXPRESS  construct  of  SET  will  map  syntactically  in  the  DATA  section  as  a 
list  data  type.  The  constraint  that  no  two  elements  of  a SET  may  have 
the  same  value  will  be  validated  at  a higher  level  than  the  file  structure. 
The  constraint  that  a SET  may  not  have  missing  members  will  be  validated  at  a 
higher  level  than  the  file  structure. 


3.4.1.  MaPDing  Example 


Entity  Definition  In  EXPRESS 


ENTITY  WIDGET;  _ 

a number:  SET  OF  INTEGER;  <-(5 
ENDIeNTITY; 


Sample  Occurrence  In  DATA  Section 


@22  » WIDGETKO. 1.2)1; 


A 


The  attribute  a^number  was  defined  by  the  set  of  numbers  0, 
1,  2 in  this  occurrence.  It  is  semantically  and  syntac- 
tically correct. 


@23  - WIDGET((0.  .2)1; 


A 


In  this  occurrence  the  attribute  is  semantically  incorrect 
according  to  the  definition  of  a SET  in  EXPRESS.  In 
EXPRESS  a SET  may  not  have  missing  or  defaulted  members. 


@24  - WIDGET((0,0,2)); 


A 


In  this  occurrence  the  attribute  is  semantically  incorrect 
according  to  the  definition  of  a SET  in  EXPRESS.  In 
EXPRESS  a SET  may  not  have  duplicate  values. 
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3.5  DEFINED  TYPE 

The  EXPRESS  construct  of  TYPE  has  no  instantiation  of  its  own  within  the  DATA 
section.  The  type  is  treated  as  the  element(s)  it  defines.  For  example,  if  a 
type  is  defined  as  a Real,  a real  number  is  put  into  the  DATA  section.  If  a 
type  is  defined  to  be  a List,  a list  is  put  into  the  DATA  section.  A mapping 
example  is  provided  below. (see  3.6.1)  Two  other  important  kinds  of  defined 
types,  the  ENUMERATION  and  the  SELECT  are  discussed  separately. 


3.5.1  MapDino  Example 


Entity  Definition  In  EXPRESS 


TYPE 
typel  - 
type2  - 
END.TYPE; 
ENTITY  WIDGET; 
attributel : 
attribute2: 
attributes: 
END.ENTITY; 


Sample  Occurrence  In  DATA  Section 


014  - WIDGET{  .T.,  256,  (1.0, 0.0)); 


3.5.2  ENUMERATION 

The  EXPRESS  construct  of  ENUMERATION  will  map  syntactically  to  the  DATA 
section  as  an  enumeration.  The  actual  value  in  an  occurrence  of  the 
enumeration  will  be  one  of  the  original  enumerated  values  enclosed  by  periods. 


INTEGER; 

LIST  [1  : 2]  of  REAL; 

LOGICAL;  < (a)  ^ 

TYPEl;  < (b)  _ 

TYPE2;  < — © 
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3.5.2. 1 MaPDina  Example 

Entity  Definition  In  EXPRESS 


TYPE 

primary  color  • ENUMERATION  OF  (RED,  GREEN,  BLUE); 
END  TYPE; 

ENTITY  WIDGET;  _ 

color:  PRIMARY  COLOR;  <-® 

END.ENTITY; 


Sample  Occurrence  In  DATA  Section 


022  - WIDGETf.RED.l; 

A 

1 

0 The  color  attribute  of  the  entity  occurrence 
contained  a value  of  RED. 


3.5.3  SELECT 

The  EXPRESS  construct  of  SELECT  has  no  instantiation  of  its  own  within  the 
DATA  section.  The  type  is  treated  as  a reference  to  or  an  occurrence  of  one  of 
the  entity  types  in  its  select-from  list.  A mapping  example  is  provided  below. 
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3. 5.3.1  MaPDino  Example 


TYPE 

AAA  « SELECT  (XXX, YYY,  ZZZ); 
END.TYPE 

ENTITY  WIDGET;  ^ 

attrl:  LIST  [1:#]  OF  AAA;  <---{a 
END.ENTITY;  ^ 


Sample  Entity  Occurrence  in  DATA  Section 


011  - XXX  (0.0, 0.0, 0.0,  1.0, 1.0, 1.0); 

012  - YYY(0. 0,0. 0,0.0,  1.0, 2. 0,0.0,  3.0,2.0,0.0) ; 

013  - WIDGETf ( #1 1. #12. XXX(3. 0.2. 0.0. 0.5.0.4.0.0.0111: 


The  attribute  attrl  in  this  entity  occurrence  had  values  of  a 
reference  to  a XXX,  a reference  to  an  YYY,  and  an  embedded  XXX 
entity  occurrence. 
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CHAPTER  4 - ENTITY  MAPPING 


4.0  ENTITY  MAPPING 

The  EXPRESS  construct  of  ENTITY  will  map  syntactically  to  the  DATA  section  as 
an  entity.  Due  to  the  possible  complexity  of  entity  definitions  in 
EXPRESS,  a number  of  mapping  examples  are  provided.  These  examples  will 
address  the  following  entity  definitions: 

0 Entities  defined  with  simple,  explicit  attributes 
0 Entities  defined  with  optional  attributes 
0 Entities  defined  with  derived  attributes 
0 Entities  defined  with  other  entities  as  attributes 
0 Entities  defined  with  WHERE  Rules 


4.1  ENTITY  WITH  EXPLICIT  ATTRIBUTES 

Entities  with  explicit  attributes  map  in  a straightforward  manner  to  the 
representative  entity  occurrences  in  the  DATA  section  of  the  exchange  format 
file  structure.  The  mapping  of  entities  with  explicit  attributes  is 
illustrated  in  the  example  below  and  described  on  the  following  page. 
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4.1.1  Mapping  Example 

Entity  Definition  In  EXPRESS 


TYPE 

primary  color  abbreviation  ■ (R,G,B); 

end.typeT 


ENTITY  WIDGET;  < 

attribute!:  INTEGER;  < (b)  ^ 

attribute2:  STRING;  < (y 

attributes:  LOGIGAL;  < 

attributeA:  REAL;  < 

attributes:  LIST  [1  : 2]  of  LOGICAL;  <•-  © _ 

attributes:  ARRAY  [-1:3]  of  INTEGER;  < © 

attribute?:  PRIMARY.COLOR  ABBREVIATION;  < 

END  ENTITY 


Sample  Entity  Occurrence  In  DATA  Section 

» WIDGET(  i,  lAl,  JL,  1^,  f.T.,.F.),  (1,0,1,2,31.  A); 


® ® © © © © 


© ® 
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0 The  EXPRESS  ENTITY-NAME  "WIDGET"  is  mapped  to  the  entity-type 
keyword  of  the  DATA  section  entity. 

NOTE:  In  order  to  optimize  file  size  yet  ensure  human  readability,  it  is 
expected  that  a table  will  be  created  to  relate  the  actual  EXPRESS 
ENTITY-NAME  to  an  abbreviated  exchange  format  entity-type 
keyword. 


e.g.,  POINT  -->  PT,  LINE  -->  LN,  etc. 


© 

© 

© 

© 

© 


attribute  1 had  a value  of  1 in  this  entity  occurrence. 

attribute  2 had  a value  of  'A'  in  this  entity  occurrence. 

attribute  3 had  a value  of  .T.  in  this  entity  occurrence. 

attribute  4 had  a value  of  1.0  in  this  entity  occurrence. 

attribute  5 was  a list  of  logicals  in  this  LIST(l)  - .T.,  LIST(2) 
entity  occurrence.  The  list  values  were; 


.F. 


attribute  6 was  an  array  of  integers  in  this  ARRAY  (-1)  - 1 
entity  occurrence.  The  array  values  were;  ARRAY  ( 0)  ■ 0 

ARRAY  ( 1)  - 1 
ARRAY  ( 2)  - 2 
ARRAY  ( 3)  - 3 


Attribute  7 was  an  enumeration.  The  entity  occurrence  contained  a value 
of  R. 


The  attribute  order  of  EXPRESS  entity  definitions  is  interpreted  such  that  the 
first  entity  attribute  below  the  EXPRESS  ENTITY-NAME  is  considered  to  be  the 
first  entity  attribute.  The  second  entity  attribute  below  the  EXPRESS 
ENTITY-NAME  is  considered  to  be  the  second  attribute,  and  so  on. 


The  EXPRESS  entity  attributes  are  mapped  one-to-one  in  the  order  indicated 
above  onto  DATA  section  entity  occurrences.  The  attribute  order  of  DATA  section 
entity  occurrences  is  defined  so  that  the  first  data  value  that  follows 
sequentially  from  the  entity-type  keyword  is  considered  to  be  the  value 
of  the  first  attribute.  The  second  value  that  follows  the  entity-type 
keyword  is  considered  to  be  the  value  of  the  second  attribute,  and  so  on. 

The  basic  data  types  of  EXPRESS  (e.g.  INTEGER,  REAL,  etc.)  are  always 
assumed  to  be  INTERNAL  attributes  to  the  entities  in  which  they  appear.  It 
is  not  permitted  to  refer  to  a simple  data  type  in  the  file  structure. 

Therefore  all  references  in  the  file  structure  must  refer  to  other  entities. 
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4.2  ENTITY  WITH  OPTIONAL  ATTRIBUTES 

Entities  with  explicit  but  optional  attributes  (assuming  the  optional  attribute 
valu.e  is  supplied)  follow  the  same  mapping  algorithm  as  entities  with  explicit 
and  required  attributes.  (Refer  to  Section  4.1,  "Entity  With  Explicit 
Attributes".)  When  the  optional  value  is  not  supplied  in  an  entity  occurrence, 
the  delimiter  that  would  have  appeared  (e.g.,  or  ")")  is  still  placed  into 
the  entity  occurrence.  The  semantics  of  missing  attribute  values  must  be 
defined  by  the  Application  Area  that  was  responsible  for  defining  the  entity. 

4.2.1  Mapping  Example 

Entity  Definition  In  EXPRESS 


ENTITY  XXX; 
attributel:  REAL; 
attribute2:  REAL; 
END_ENTITY; 


ENTITY  YYY;  < 

attributel:  OPTIONAL  LOGICAL; 
attribute2;  EXTERNAL  POINT  ; 
attributes:  EXTERNAL  POINT  ; 
attribute4:  OPTIONAL  INTEGER; 
attributes:  OPTIONAL  REAL;  < 
END.ENTITY; 


Sample  Entity  Occurrences  In  DATA  Section 


@1-XXX(1. 0,2.0); 
02»XXX(3. 0,4.0); 


022-YYY( 

il  I 111 

(a)®(cXSXIXD 
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© The  EXPRESS  ENTITY-NAME  "YYY"  is  mapped  to  the  entity-type 
keyword  of  the  DATA  Section  entity. 

attribute  1 does  not  have  a value  in  this  entity  occurrence, 

attribute  2 is  a reference  to  the  XXX  entity  with  entity  identifier  2. 

attribute  3 is  a reference  to  the  XXX  entity  with  entity  identifier  1. 

attribute  4 does  not  have  a value  in  this  entity  occurrence, 

attribute  5 does  not  have  a value  in  this  entity  occurrence. 
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4.3  ENTITY  WITH  DERIVED  ATTRIBUTES 

Derived  attributes  contain  information  about  an  entity  in  addition  to 
containing  those  attributes  that  define  the  entity  explicitly  and  completely. 
The  derived  attributes  carry  redundant  information  since  they  can  be  calculated 
from  the  explicit  attributes. 

Derived  attributes  do  not  map  to  the  DATA  section:  only  explicit  attributes  are 
mapped.  In  the  example  below,  note  that  the  derived  attributes  (attribS  and 
attrib4)  do  not  appear  in  the  entity  occurrence. 


4.3.1  MaPDina  Example 


Entity  Definition  In  EXPRESS 


ENTITY  XXX; 
pO:  YYY; 
pi:  YYY; 
p2:  YYY; 
DERIVE 
attribS  - 
attrib4  ■ 
END.ENTITY; 


FUNC  NORMAL  (P0,P1,P2);  <--  (?) 

FUNC„DIAMETER  (PO, PI, P2)  — 


Sample  Entity  Occurrences  In  DATA  Section 


09 

010 

011 

012 


YYY(  0.0,  0.0,  0.0); 
YYY(  1.0,  2.0,  3.0); 
INT(  4.0,  5.0,  6.0); 


XXXf  #9,  #10,  # 


): 


© © 
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0 The  EXPRESS  ENTITY-NAME  "XXX"  is  mapped  to  the  entity-type 
keyword  of  the  DATA  Section  entity. 

0 pO  is  a reference  to  the  YYY  entity  with  an  entity  identifier  of  9. 

0 pi  is  a reference  to  the  YYY  entity  with  an  entity  identifier  of  10. 

0 p3  is  a reference  to  the  YYY  entity  with  an  entity  identifier  of  11. 

0 attribS  does  not  map  to  the  entity  occurrence. 

0 attrib4  does  not  map  to  the  entity  occurrence. 
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4.4  ENTITY  WITH  ENTITY  ATTRIBUTES 

When  an  entity  is  specified  as  an  attribute  of  a second  (parent)  entity,  the 
first  (child)  entity  will  be  mapped  to  the  DATA  section  as  either  an  entity 
reference  or  an  embedded  entity.  The  exact  mapping  is  controlled  by 
the  presence  or  absence  of  specific  keywords  within  the  attribute  declaration; 
INTERNAL  and  EXTERNAL. 

If  the  keyword  INTERNAL  is  present,  the  entity  will  map  to  an  embedded 
entity.  If  the  keyword  EXTERNAL  is  present,  the  entity  will  map  to  an 
entity  reference.  If  neither  keyword  is  present,  or  if  the  keyword 
DYNAMIC  appears,  the  entity  may  legally  map  to  either  an  embedded 
entity  or  an  entity  reference. 


4.4.1  Entities  As  Internal  Attributes 

When  the  keyword  INTERNAL  is  present,  an  entity  declared  as  an  attribute  will 
map  to  an  embedded  entity.  The  syntax  of  an  embedded  entity  can  be 
found  in  STEP  Document  4.2.1,  The  STEP  File  Structure.  If  the  child  entity  is 
not  a SUPERTYPE,  then  the  entity  type  keyword  is  optional.  Since  the 
embedded  entity  must  always  be  of  the  same  type,  the  entity  type  keyword 
is  not  required  for  unambiguous  processing  of  the  exchange  file.  If  the  child 
entity  is  a SUPERTYPE,  then  the  entity  type  keyword  is  required  because 
of  the  select  from  functionality  of  EXPRESS'S  SUPERTYPE  construct. 

The  significance  of  an  embedded  entity  is  that  the  sending  CAD  system 
does  not  intend  for  the  receiving  CAD  system  to  create  the  embedded 
entity  as  an  independent  entity  within  the  database  of  the  receiving 
system.  The  emb^ded  entity  is  present  only  for  the  purposes  of 
constructing  the  parent  entity.  If  the  parent  entity  cannot  be  constructed 
within  the  receiving  database,  the  embedded  entity  should  not  be 
constructed. 


4. 4. 1.1  Mapping  Example 


Entity  Definition  In  EXPRESS 


ENTITY  YYY; 
x:  REAL; 
y:  REAL; 
z:  REAL; 
END.ENTITY; 


ENTITY  XXX;  <•- 
pO:  INTERNAL 


pi:  INTERNAL 
END  ENTITY; 
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Sample  Entity  Occurrence  In  DATA  Section 

(?30  » XXX(  YYYf  0.0.  1.0.  2.0)  , YYYf  1.0.  2.0.  2.0)): 


i (!) 


(b 


@ The  EXPRESS  ENTITY-NAME  "XXX"  is  mapped  to  the  entity-type 
keyword  of  the  DATA  Section  entity. 

pO  is  mapped  to  an  embedded  YYY  entity  in  this  entity  occurrence. 
© pi  is  mapped  to  an  embedded  YYY  entity  in  this  entity  occurrence. 


Another  Sample  Entity  Occurrence  In  DATA  Section 
@31  - XXX(  ( 0.0,  1.0.  2.0)  , ( I.O,  2.0.  3.01  ); 

(D)  ci)  b 

® The  EXPRESS  ENTITY-NAME  "XXX"  is  mapped  to  the  entity-type 
keyword  of  the  DATA  Section  entity. 

© pO  is  mapped  to  an  embedded  YYY  entity  in  this  entity  occurrence. 
© pi  is  mapped  to  an  embedded  YYY  entity  in  this  entity  occurrence. 


4.4.2  Entities  As  External  Attributes 

When  the  keyword  EXTERNAL  is  present,  an  entity  declared  as  an  attribute  will 
map  to  an  entity  reference.  The  syntax  of  an  entity  reference  can 
be  found  in  STEP  Document  Normative  ANNEX  B,  "The  STEP  File  Structure".  If  the 
keyword  EXTERNAL  is  used,  it  Is  illegal  for  an  entity  attribute  to  be 
embedded  in  a parent  entity. 

The  significance  of  an  entity  reference  is  that  the  sending  CAD  system  intends 
for  the  receiving  CAD  system  to  create  the  referred  entity  as  an  independent, 
sharable  entity  within  the  database  of  the  receiving  system. 
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4. 4. 2.1  Mapping  Example 

Entity  Definition  In  EXPRESS 


ENTITY  YYY; 
x:  REAL; 
y:  REAL; 
z:  REAL; 

END  ENTITY; 


ENTITY  XXX;  < 

pO:  EXTERNAL  YYY  ; < 
pi:  EXTERNAL  YYY  ; < 
END  ENTITY; 


Sample  Entity  Occurrences  In  DATA  Section 
@9  - YYY{4.0,  5.0,  6.0); 

@10  - YYY(1.0,  2.0,  3.0); 

@11  - XXX(#9,  #10); 


@ The  EXPRESS  ENTITY-NAME  "XXX"  is  mapped  to  the  entity-type 
keyword  of  the  DATA  Section  entity. 

pO  is  a reference  to  a YYY  entity  with  an  entity  identifier  of  9. 
© pi  is  a reference  to  a YYY  entity  with  an  entity  identifier  of  10. 
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4.4.3  Entities  as  Dynamic  Attributes 

When  the  keyword  DYNAMIC  is  present  or  when  neither  the  keywords  INTERNAL 
nor  EXTERNAL  is  present,  an  entity  declared  as  an  attribute  may  legally  map 
to  an  embedded  entity  or  an  entity  reference.  The  syntax  of 
embedded  entities  and  entity  references  can  be  found  in  STEP  Document  Normative 
ANNEX  B,  "The  STEP  File  Structure". 

If  the  entity  that  has  been  declared  as  an  attribute  is  not  a SUPERTYPE,  then 
the  entity  type  keyword  is  optional.  Since  the  embedded  entity  must 
always  be  of  the  same  type,  the  entity  type  keyword  is  not  required  for 
unambiguous  processing  of  the  exchange  file.  If  the  entity  that  has  been 
declared  as  an  attribute  is  a SUPERTYPE,  then  the  entity  type  keyword 
is  required  because  of  the  select  from  functionality  of  EXPRESS'S  SUPERTYPE 
construct. 

The  significance  of  the  2 mappings  is  specified  in  Chapters  4.4.1  and  4.4.2. 


4.4.3. 1 Mapping  Example 


Entity  Definition  in  EXPRESS 


ENTITY  YYY; 
X : REAL; 
y : REAL; 
z : REAL; 
END  ENTITY; 


ENTITY  XXX  < 

pO  : DYNAMIC  YYY  < 
pi  : DYNAMIC  YYY  < 
END  ENTITY; 


Sample  Entity  Occurence  in  DATA  Section 

07  - YYY(3.,  4..  5.) 

09  - XXXfYYYd.,  2.,  3.),  #7); 

(a)  (b)  (c) 

The  EXPRESS  ENTITY  NAME  "XXX"  is  mapped  to  the  entity  type 
keyword  of  the  DATA  section  entity. 

The  attribute  pO  is  mapped  to  an  embedded  YYY  entity  in  this  occurrence. 

The  attribute  pi  is  mapped  to  an  entity  reference  in  this  entity 

occurrence. 
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4.5  ENTITIES  AS  SUBTYPES 

When  an  EXPRESS  entity  is  labeled  as  a SUBTYPE  of  some  other  entity(s)  it 
will  inherit  the  attributes  of  the  SUPERTYPE  entity(s).  The  order  of  the 
attribute  inheritance  is  as  follows: 


0 All  inherited  attributes  will  appear  sequentially  prior  to  the  defining 
attributes  of  any  entity. 

0 The  attributes  of  a SUPERTYPE  entity  are  inherited  in  the  order  they 
appear  in  the  SUPERTYPE  entity  itself. 

0 If  the  SUPERTYPE  entity  is  itself  a SUBTYPE  of  another  entity,  then 
the  attributes  of  the  higher  SUPERTYPE  entity  are  inherited  first. 

0 When  multiple  SUPERTYPE  entities  are  listed,  the  list  is  processed 
left  to  right. 


4.5.1  MaoDinQ  Example 


Entity  Definition  in  EXPRESS 

ENTITY  AAA  SUPERTYPE  OF  (BBB);  < ® _ 

tm:  EXTERNAL  ZZZ;  < — (b) 

END  ENTITY; 


ENTITY  BBB  SUBTYPE  OF  (AAA)  SUPERTYPE  OF  (XXX); 


pO:  EXTERNAL  YYY;  <• 
pi:  EXTERNAL  YYY;  <■ 
END  ENTITY; 


© 


© 


ENTITY  CCC  SUPERTYPE  OF  (XXX);  < 

parameterization  : REAL;  < 

END.ENTITY; 


ENTITY  XXX  SUBTYPE  OF  (BBB,  CCC);  < 

mi  dpt:  EXTERNAL  YYY;  < 

END  ENTITY; 


© 
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© 

© 

© 

© 

© 
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Sample  Entity  Occurence  in  DATA  Section 


01 

02 

03 

04 

05 


ZZZ(1.,  0.,  0.,  0.,  0.,  1..  0.,  0.,  0.,  0..  1.,  0.); 
YYY(1.0,  2.0,  0.0) 

YYY(2.0,  2.0,  0.0) 

YYY(1.5,  2.5,  0.0) 


XXX(#1,  #2,  #3,  1.0,  #4); 


Since  entity  AAA  is  a SUPERTYPE,  it  will  not  map  to  the  DATA  Section 
of  the  exchange  format  file. 

The  attribute  tm  will  map  to  the  DATA  Section  as  an  inherited  attribute 
in  an  entity  that  is  directly  or  indirectly  subtyped  to  the  AAA  entity. 
In  this  case,  tm  is  represented  by  the  ZZZ  entity  with  the  entity 
identifier  of  ''01'*. 


Since  entity  BBS  is  a SUPERTYPE,  it  will  not  map  to  the  DATA  Section 
of  the  exchange  format  file. 

The  attribute  pO  will  map  to  the  DATA  Section  as  an  inherited  attribute 
in  an  entity  that  is  directly  or  indirectly  subtyped  to  the  AAA  entity. 
In  this  case,  pO  is  represented  by  the  YYY  entity  with  the  entity 
identifier  "02". 

The  attribute  pi  will  map  to  the  DATA  Section  as  an  inherited  attribute 
in  an  entity  that  is  directly  or  indirectly  subtyped  to  the  AAA  entity. 
In  this  case,  pi  is  represented  by  the  YYY  entity  with  the  entity 
identifier  "03". 


Since  entity  CCC  is  a SUPERTYPE,  it  will  not  map  to  the  DATA  Section 
of  the  exchange  format  file. 

The  attribute  parameterization  will  map  to  the  DATA  Section  as  an 
inherited  attribute  in  an  entity  that  is  directly  or  indirectly  subtyped 
to  the  AAA  entity.  In  this  case,  the  parameterization  value  is  1.0. 

The  EXPRESS  EMTITY  NAME  "XXX"  is  mapped  to  the  entity  type 
keyword  of  the  DATA  Section  entity. 

Attribute  midpt  is  represented  by  the  YYY  entity  with  the  entity 
identifier  of  "04". 
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4.6  ENTITIES  AS  SUPERTYPES 

Entities  that  are  declared  as  supertypes  of  other  entities  will  not  map 
directly  to  the  DATA  Section  of  the  exchange  format  file.  The  attributes  of 
those  supertype  entities  will  be  migrated  into  the  subtyped  entities.  See 
Section  4.5  for  a detailed  description  of  the  attribute  migration. 
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4.7  ENTITY  WITH  WHERE  RULES 

Only  attributes  that  are  explicitly  declared  are  mapped  to  the  DATA  section. 
Therefore,  WHERE  rules  do  not  map  to  the  DATA  section.  In  the  example  below, 
note  that  the  WHERE  rules  are  not  instantiated  in  the  entity  occurrence. 

The  information  contained  within  the  WHERE  rules  can  be  used  to  validate  the 
information  within  the  entity  occurrence.  However,  the  WHERE  rules 
themselves  are  not  represented  in  the  exchange  format  file. 


4.7.1  Mapping  Example 

Entity  Definition  In  EXPRESS 


ENTITY  WIDGET;  < (a)  _ 

a:  REAL;  < — (F  _ 

b:  REAL;  < VK’--  © 

c:  REAL;  < © 

WHERE 

a **  2 + b **  2 + c **  2 - 3.0;  <--© 
END.ENTITY; 


Sample  Entity  Occurrence  In  DATA  Section 


022  « WIDGETC  1.0,  1.0,  2.0); 


© © 


© ® 


@ The  EXPRESS  ENTITY  NAME  "WIDGET"  is  mapped  to  the  entity  type 
keyword  of  the  DATA  section  entity. 

@ Attribute  a had  a value  of  1.0  in  the  entity  occurence. 

© Attribute  b had  a value  of  1.0  in  the  entity  occurence. 

© Attribute  c had  a value  of  2.0  in  the  entity  occurence. 

© The  WHERE  rule  did  not  map  to  the  DATA  section.  In  this  case,  the 

entity  is  syntactically  correct,  but  semantically  incorrect. 
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CHAPTER  5 - SCHEMA 

5.0  SCHEMA 

The  EXPRESS  construct  of  SCHEMA  does  not  map  to  the  DATA  Section. 
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CHAPTER  6 • REMARKS 

6.0  REMARKS 

Remarks  do  not  map  to  the  DATA  section. 
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Section  1:  INTEGRATION  CORE  MODEL 


1.1  Purpose 

The  purpose  of  the  data  model  described  herein  is  to  provide  a fundamental  data 
structure  for  the  shape  definition  of  a product  item  and  its  various  geometric 
representations.  The  data  structure  is  independent  of  the  type  of  product.  Whether 
it  be  strictly  mechanical,  electrical,  architectural,  construction,  or  of  some  other  type, 
the  model  can  satisfy  the  requirements  to  provide  the  shape  definition  and  shape 
geometric  representations. 


1.2  Scope 

The  scope  of  the  Integration  Core  Model  evolves  as  more  PDES  topical  models 
become  ready  to  be  integrated.  The  initial  scope  of  the  model  is  focused  on  models 
that  contain  shareable  information,  such  as  geometry.  Product  Structure 
Configuration  Management,  Form  Feature,  Tolerance,  etc.  The  model  does  not 
contain  information  that  is  specific  to  an  application  area,  such  as  Mechanical 
Product,  Electric  Product,  Architectural  Product,  etc.  The  scope  of  the  integration 
core  model  will  expand  to  contain  integration  information  necessary  for  the 
purpose  to  indicate  how  the  shareable  data  is  used  for  an  application  area. 

At  any  point  of  time,  the  Integration  Core  Model  represents  a consolidated 
viewpoint  of  all  models  that  are  addressed.  Eventually,  the  Integration  Core  Model 
will  represent  the  viewpoint  of  PDES  total  scope. 


1.3  Fundamental  Concepts  and  Assumptions 

The  Integration  Core  Model  was  based  on  a fundamental  conceptual  idea — that  is, 
the  elements  of  shape  that  are  used  to  reference  the  form  of  a real  or  conceived 
object  are  independent  from  any  specific  geometric  and  topological  elements  (e.g, 
face,  vertex,  point,  etc.)  that  are  associated  with  specific  rules  of  a representation 
method.  A clear  distinction  was  made  between  referenceable  shape  elements  on  a 
real  or  conceived  object  and  the  mechanism  used  to  represent  that  shape  element. 

The  structure  of  the  Integration  Core  Model  is  very  extendible.  The  separation  of 
the  referenceable  shape  elements  from  their  representations  allows  expansion  of 
additional  representations.  The  establishment  of  the  referenceable  shape  elements 
provides  a framework  for  elements  of  the  descriptive  identification  of  the  physical 
form  of  any  product  item.  It  also  allows  for  future  expansion  when  requirements 
arise. 
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For  each  identified  shape  element,  relationships  were  established  to  all  of  its  knowm 
possible  representations.  The  following  table  was  used  to  capture  the  relationships 
and  guide  the  development  of  the  Integration  Core  Model: 


Referenceable  Shape  Element  and  Representation 
Geometric  Model  Relationship  Tables 


Dimensionality-3  Shape  Element  Representation  Table 


Model 

Obiect 

Voidless  Volume 

Obiect  Assembly 

Brep 

Entire  model 

Shell 

Facetted  Brep 

Entire  model 

Shell 

CSG  Solid 

Entire  model 

Entire  model 

Entire 

model 

C5G  Primitive 

Entire  model 

Surface 

Entire  model 

Entire  model 

Entire 

model 

Half  Space 

Entire  model 

Wireframe 

Entire  model 

Entire  model 

Entire 

model 

SOR  (Complete) 

Entire  model 

Loop  log.  struct. 

SOR  (Partial) 

Entire  model 

SOLE 

Entire  model 

Unstruct.  Geom. 

Entire  model 

Entire  model 

Entire 

model 

Geom.  Assembly 

Entire 

model 

Dimensionality-2  Shape  Element  Representation  Table 


Model 

Area 

Maximal  Area 

Nonmaximal  Area 

Brep 

Face 

Subface 

Facetted  Brep 

Face 

Subface 

CSG  Solid 

CSG  Primitive 

Surface 

Face 

Subface 

Half  Space 

Wireframe 

Loop 

SOR  (Complete) 

Edge 

Edge  (1) 

SOR  (Partial) 

Edge 

Face 

Subface,  Edge  (1) 

SOLE 

Edge 

Face 

Subface,  Edge  (1) 

Unstruct.  Geom. 

Geometry 

Geom.  Assembly 

Note  1:  Edge  on  subface. 
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iviuaei 

Seam 

Perimeter 

Brep 

Edge 

Loop 

Facetted  Brep 

Polyloop 

CSG  Solid 

CSG  Primitive 
Surface 

Edge 

Loop 

Half  Space 
Wireframe 

Edge 

Loop 

SOR  (Complete) 

Vertex 

Vertex 

50R  (Partial) 

Edge,  Vertex 

Loop,  Edge 

SOLE 

Edge,  Vertex 

Loop,  Edge 

Unstruct.  Geom. 
Geom.  Assembly 

Geometry 

Geometry 

N2  3 


Dimensionalit-v’-O  Shape  Element  Representation  Table 


Model 

Corner 

Boundary  Location 

Interior  Location 

Brep 

Vertex 

Vertex  (1) 

Vertex  (1) 

Facetted  Brep 

CSG  Solid 

CSG  Primitive 

Point 

Point  (2) 

Point  (2) 

Surface 

Half  Space 

Vertex 

Vertex  (1) 

Vertex  (1) 

Wireframe 

Vertex 

Vertex  (1) 

Vertex  (1) 

SOR  (Complete) 

Vertex 

Vertex  (1) 

SOR  (Partial) 

Vertex 

Vertex  (1) 

Vertex  (1) 

SOLE 

Vertex 

Vertex  (1) 

Vertex  (1) 

Unstruct.  Geom. 
Geom.  Assembly 

Geometry 

Geometry 

Geometry 

Note  1:  Vertex  on  nonmax  face. 
Note  2:  Point  on  nonmax  polyloop. 
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Assumptions  were  made  that  the  PDES  Integrated  Product  Data  Model  (EPDM)  must 
address  the  following  issues: 

(1)  PDES  must  include  various  types  of  geometric  models,  i.e..  Boundary 
Representation,  CSG,  Surface,  Extrusion,  Wireframe,  Solid  of  Revolution, 
Facetted  Boundary  Representation,  Geometry,  and  a mixture  of  several 

representations. 

(2)  To  describe  the  same  physical  form /shape  of  a product  item,  many  possible 
representations  can  be  and  will  be  used 

(3)  It  is  necessary  to  identify  the  correspondences  between  geometric  entities  that 
belong  to  different  geometric  models  when  they  represent  the  same  physical 
form /shape  of  a product  item. 

(4)  PDES  will  allow  geometry  to  be  exchanged  independent  of  its  association  with  a 
product  item,  e.g.,  standard  shape 


1.4  Abbreviations  and  Acronyms 

The  following  abbreviations  and  acronyms  are  used  throughout  this  document. 

Brep  Boundary  Representation 

DIM-0  Dimensionality-0 

DIM-1  Dimensionality-1 

DIM-2  Dimensionality-2 

DIM-3  Dimensionality-3 

PDES  Product  Data  Exchange  Specification 

PI  Product  Item 

PIV  Product  Item  Version 

PSCM  Product  Structure  Configuration  Management 

SE  Shape  Element 

SML  Structured  Modeling  Language 

SOLE  Solids  of  Linear  Extrusion 

SOR  Solids  of  Revolution 
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Section  1:  INTEGRATION  CORE  MODEL 


2.  INTEGRATION  PLANNING  MODEL 

This  section  describes  the  planning  model  for  the  Integration  model.  This  planning 
model  serves  as  a high-level  overview  of  the  scope  of  the  model  and  as  a starting 
point  for  the  development  of  the  detailed  reference  model. 

2.1  Entity  Pool 

The  Integration  planning  model  consists  of  the  follovvdng  entities,  which  are  defined 
on  subsequent  pages: 

Entity  No.  Entity  Name 


Shape 

Shape  Element 


INT-1 

INT-2 


The  Integration  planning  model  also  contains  the  following  entities,  which  are  (or 
need  to  be)  defined  in  other  PDES  reference  models: 


Entity  No. 


Entity  Name 


PSCM-1 

PSCM-2 


Product  Item 
Product  Item  Version 


GEO-84 

GEO-85 

GEO-86 

GE087 

GEO-88 

GEO-106 

GEO-107 


CSG  Primitive  Model 
CSG  Solid  Model 


Facetted  Brep  Model 
Half  Space  Model 
Manifold  Solid  Brep  Model 
Solid  of  Linear  Extrusion  Model 
Solid  of  Revolution  Model 


Surface  Model 
Wireframe  Model 
Unstructured  Geometry  Model 
Geometric  Assembly  Model 
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2.2  Planning  Model  Diagram 


planning  model  goes  here 
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Entity 

CSG  Primitive  Model 

Entity  Numbpr- 

geo-84 

Entity  Definition 

. Defined  in  the  PDES  Geometry  reference  model. 

Business  Rules: 

Every  "CSG  Primitive  Model": 

represents  zero,  one,  or  more  "Shape  Elements". 

Entity  Name: 

CSG  Solid  Model 

Entity  Number: 

GEO-85 

Entity  Definition- 

Defined  in  the  PDES  Geometry  reference  model. 

Business  Rules- 

Every  "CSG  Solid  Model": 

• represents  zero,  one,  or  more  "Shape  Elements". 

Entity  Name: 

Facetted  Brep  Model 

Entity  Number: 

GEO-86 

Entity  Definition- 

Defined  in  the  PDES  Geometry  reference  model. 

Business  Rules- 

Every  "Facetted  Brep  Model": 

• represents  zero,  one,  or  more  "Shape  Elements". 

Entity  Name- 

Geometric  Assembly  Model 

Entity  Number- 

none 

Entity  Definition: 

Needs  to  be  defined  in  some  other  PDES  reference  model 

Business  Rules- 

Every  "Geometric  Assembly  Model": 

• represents  zero,  one,  or  more  "Shape  Elements". 

r.2 
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Entity  Varr.e:  Half  Space  Model 

Entity  Number:  GE087 

Emitv  Definition:  Defined  in  the  PDES  Geometry  reference  model. 

Business  Rules:  Every  "Half  Space  Model": 

• represents  zero,  one,  or  more  "Shape  Elements". 


Entity  aVame:  Manifold  Solid  Brep  Model 

Entity  Number:  GEO-88 


Entity  Definition:  Defined  in  the  PDES  Geometry  reference  model 

Business  Rules:  Every  "Manifold  Solid  Brep  Model": 

• represents  zero,  one,  or  more  "Shape  Elements". 


Entity  Name:  Product  Item 

Entity  Number:  PSCM-1 


Emitv  Definition:  Defined  in  the  PDES  PSCM  reference  model. 

Business  RuIp^-.  Every  "Product  Item": 

• has  one  or  more  "Product  Item  Versions". 


Entity  Name:  Product  Item  Version 


Entity  Number:  PSCM-2 

Entity  Definition:  Defined  in  the  PDES  PSCM  reference  model. 

Business  Rules:  Eyery  "Product  Item  Version": 

• is  for  one,  and  only  one,  "Product  Item". 

• has  a primary  shape  of  zero,  one,  or  more  "Shapes". 


^’2S8 
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Fntitv  Name: 


Sectxon  1:  INTEGRATION  CORE  MODEL 

Shape 


Entity  Number:  INT-1 


Entity  Definition:  The  spatial  configuration,  and  proportions  of  a real  or 
conceiyed  thing,  independent  of  whether  or  how  it  is 
represented. 

Business  Rules:  Eyery  "Shape": 

• is  an  ag^egation  zero,  one,  or  more  "Shape  Elements". 

• is  the  primary  shape  for  zero,  one,  more  "Product  Item 
Versions". 


Entity  Name:  Shape  Element 


Entity  Number:  INT-2 


Entity  Definition:  A distinguishable  aspect  of  a "Shape". 

Business  Rules:  Eyery  "Shape  Element": 

• is  part  of  one,  and  only  one,  "Shape". 

• is  represented  by  zero,  one,  or  more  "CSG  Primitiye 
Models". 

• is  represented  by  zero,  one,  or  more  "CSG  Solid  Models". 

• is  represented  by  zero,  one,  or  more  "Facetted  Brep 
Models". 

• is  represented  by  zero,  one,  or  more  "Geometric  Assembly 
Models". 

• is  represented  by  zero,  one,  or  more  "Half  Space  Models". 

• is  represented  by  zero,  one,  or  more  "Manifold  Solid  Brep 
Models". 

• is  represented  by  zero,  one,  or  more  "Solid  of  Linear 
Extrusion  Models". 

• is  represented  by  zero,  one,  or  more  "Solid  of  Revolution 
Models". 

• is  represented  by  zero,  one,  or  more  "Surface  Models". 

• is  represented  by  zero,  one,  or  more  "Unstructured 
Geometry  Models". 

• is  represented  by  zero,  one,  or  more  "Wireframe  Models". 
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SecUon  1:  INTEGRATION  CORE  MODEL 

Entity  Name: 

Solid  of  Linear  Extrusion  Model 

Entity  Number; 

GEO-106 

Entity  Definition: 

Defined  in  the  PDES  Geometry  reference  model. 

Business  Rules; 

Every  "Solid  of  Linear  Extrusion  Model": 

• represents  zero,  one,  or  more  "Shape  Elements". 

Entity  Name: 

Solid  of  Revolution  Model 

Entity  Number. 

GEO107 

Entity  Definition: 

Defined  in  the  PDES  Geometry  reference  model. 

Business  Rules: 

Every  "Solid  of  Revolution  Model": 

• represents  zero,  one,  or  more  "Shape  Elements”. 

Entity  Name: 

Surface  Model 

Entity  Number: 

none 

Entity  Definition; 

Needs  to  be  defined  in  some  other  PDES  reference  model. 

Business  Rules: 

Every  "Surface  Model": 

• represents  zero,  one,  or  more  "Shape  Elements". 

Entity  Name: 

Unstructured  Geometry  Model 

Entity  Number: 

none 

Entity  Definition; 

Needs  to  be  defined  in  some  other  PDES  reference  model. 

Business  Rules: 

Every  'Unstructured  Geometry  Model": 

• represents  zero,  one,  or  more  "Shape  Elements". 
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Entity  Name:  Wireframe  Model 

Entity  Number:  none 

Entity  Definition:  Needs  to  be  defined  in  some  other  PDES  reference  model. 

Business  Rules:  Every  "Wireframe  Model": 

• represents  zero,  one,  or  more  "Shape  Elements". 


N2 
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Section  1:  INTEGRATION  CORE  MODEL 

3.  INTEGRATION  REFERENCE  MODEL 

This  section  describes  the  reference  model  for  the  Integration  model.  This  reference 
model  is  depicted  in  15  individual  views: 

1.  Shape 

2.  Geometric  Models 

3.  Dimensionality-3 

4.  Object 

5.  Voidless  Volume 

6.  Object  Assembly 

7.  Area 

8.  Maximal  Area 

9.  Nonmaximal  Area 

10.  Seam 

11.  Perimeter 

12.  Dimensionality-0 

13.  Corner 

14.  Boundary  Location 

15.  Interior  Location 
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3.1  Entity  Pool 

The  Integration  reference  model  consists  of  the  following  entities,  which  are  defined 


on  suDsequent  pages: 

Entity  No. 

Entity  Name 

INT-1 

Shape 

INT-2 

Shape  Element 

INT-3 

Dimensionality  3 Shape  Element 

INT-4 

Object  Shape  Element 

IXT-5 

Voidless  Volume  Shape  Element 

INT-6 

Object  Assembly  Shape  Element 

INT-7 

Dimensionality  2 Shape  Element 

INT-8 

Area  Shape  Element 

INT-9 

Maximal  Area  Shape  Element 

LNT-10 

Nonmaximal  Area  Shape  Element 

INT-1 1 

Zone  Shape  Element 

INT-1 3 

Dimensionality  1 Shape  Element 

INT-1 4 

Seam  Shape  Element 

INT-15 

Edge  Shape  Element 

INT-16 

Subedge  Shape  Element 

INT-17 

Interior  Seam  Shape  Element 

INT-1 8 

Perimeter  Shape  Element 

INT-1 9 

Dimensionality  0 Shape  Element 

INT-20 

Comer  Shape  Element 

INT-21 

Boundary  location  Shape  Element 

INT-22 

Interior  Location  Shape  Element 

INT-23 

Geometric  Model 

INT-24 

Pair  of  EquiyaJent  Geometric  Models 

INT-25 

Dim  3 Shape  Element  Representation 

LNT-26 

CSG  Solid  Dim  3 SE  Rep 

LNT-27 

Surface  Dim  3 SE  Rep 

INT-28 

Wireframe  Dim  3 SE  Rep 

INT-29 

Unstruct  Geometry  Dim  3 SE  Rep 

INT-30 

Object  Representation 

INT-3 1 

Brep  Object  Rep 

INT-32 

Facetted  Brep  Object  Rep 

INT-33 

Full  Rey  SOR  Object  Rep 

INT-34 

Voidless  Volume  Representation 

INT-35 

Brep  Volume  Rep 

INT-36 

CSG  Primitiye  Volume  Rep 

lNT-37 

Half  Space  Volume  Rep 

INT-3  8 

Partial  Rey  SOR  Volume  Rep 

INT-39 

Full  Rey  SOR  Volume  Rep 
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INT-40 

SOLE  Volume  Rep 

INT-41 

Object  Assembly  Representation 

INT-42 

Area  Representation 

INT-43 

Brep  Area  Rep 

INT-44 

Facetted  Brep  Area  Rep 

INT-45 

Surface  Area  Rep 

iNT-46 

Partial  Rev  SOR  Max  Area  Rep 

INT-47 

SOLE  Max  Area  Rep 

INT-48 

Wireframe  Area  Rep 

L\T-49 

SOR  Edge  Area  Rep 

INT-50 

SOLE  Edge  Area  Rep 

INT-51 

Unstruct  Geometry  Area  Rep 

L\T-52 

Nonmaximal  Area  Representation 

INT-53 

Brep  NM  Area  Rep 

INT-54 

Facetted  Brep  NM  Area  Rep 

INT-55 

Surface  NM  Area  Rep 

INT-56 

Partial  Rev  SOR  Subface  NM  Area  Rep 

INT-57 

SOLE  Subface  NM  Area  Rep 

L\T-59 

SOR  Edge  NM  Area  Rep 

INT-60 

SOLE  Edge  NM  Area  Rep 

INT-63 

Seam  Representation 

INT-64 

Brep  Seam  Rep 

INT-65 

Surface  Seam  Rep 

INT-66 

Wireframe  Seam  Rep 

INT-67 

Partial  Rev  SOR  Edge  Seam  Rep 

INT-68 

SOLE  Edge  Seam  Rep 

INT-70 

SOR  Vertex  Seam  Rep 

INT-71 

SOLE  Vertex  Seam  Rep 

INT-72 

Unstruct  Geometry  Seam  Rep 

L\T-73 

Perimeter  Representation 

LNT-74 

Brep  Perimeter  Rep 

INT-75 

Surface  Perimeter  Rep 

INT-76 

Wireframe  Perimeter  Rep 

INT-77 

Partial  Rev  SOR  Loop  Perimeter  Rep 

INT-78 

SOLE  Loop  Perimeter  Rep 

INT-79 

Facetted  Brep  Perimeter  Rep 

INT-80 

Full  Rev  SOR  Vertex  Perimeter  Rep 

INT-81 

Partial  Rev  SOR  Edge  Perimeter  Rep 

INT-82 

SOLE  Edge  Perimeter  Rep 

INT-83 

Unstruct  Geometry  Perimeter  Rep 

INT-84 

Dim  0 Shap>€  Element  Representation 

L\'T-85 

Brep  Dim  0 SE  Rep 

INT-86 

Surface  Dim  0 SE  Rep 

LNT-87 

Wireframe  Dim  0 SE  Rep 

INT-88 

SOLE  Dim  0 SE  Rep 

N288 


Page  D3.1.M6 


ISO  TC184/SC4/WG1 

ANNEX  D November  22,  1988  N2S3 

(Draft  Proposal) 

SecUon  1:  INTEGRATION  CORE  MODEL 

IXT-S9 

INT-90 

INT-91 

INT-92 

INT-93 

INT-97 

INT-99 

INT-100 

INT-101 

INT-103 

INT-104 

INT-105 

Facetted  Brep  Dim  0 SE  Rep 

Unstruct  Geometry  Dim  0 SE  Rep 

Comer  Representation 

Full  Rev  SOR  Comer  Rep 

Partial  Rev  SOR  Comer  Rep 

Partial  Rev  SOR  Bdry  Loc  Rep 

Interior  Location  Representation 

Full  Rev  SOR  Int  Loc  Rep 

Partial  Rev  SOR  Int  Loc  Rep 

Zone  Shap)e  Element  Component 

Facetted  Brep  Volume  Rep 

Maximal  Area  Representation 

The  Integration  reference  model  also  contains  the  following  entities,  which  are  (or 
need  to  be)  defined  in  other  PDES  reference  models: 


Entitv  No. 

Entitv  Name 

FF-001 

Form  Feature 

TOP-2 

TOP-3 

TOP-4 

TOP-5 

TOP-6 

TOP-8 

TOP-11 

TOP-25 

Vertex 

Edge 

Loop 

Face 

Shell 

Subface 

Polyloop 

Loop  Logical  Structure 

GEO-1 

GEO-2 

GEO-84 

GEO-85 

GEO-86 

GEO-87 

GEO-88 

GEO-106 

GEO-1 07 

Geometry 

Point 

CSG  Primitive  Model 

CSG  Solid  Model 

Facetted  Brep  Model 

Half  Space  Model 

Manifold  Solid  Brep  Model 

Solid  of  Linear  Extrusion  Model 

Solid  of  Revolution  Model 

Surface  Model 

Wireframe  Model 

Unstructured  Geometry  Model 

Geometric  Assembly  Model 
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PSCM-1 

PSCM-2 

PSCM-4 

PSCM-27 

FEM-1 

FEM-2 


I.’ 2 


Section  1:  INTEGRATION  CORE  MODEL 

Product  Item 
Product  Item  Version 

Product  Item  Version  Functional  Definition 
Product  Item  Version  Definition  Shape 

FEM 

FEM  Product  Item  Version  Definition 
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3-2  Reference  Model  Diagrarrn; 
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N238 


Section  1:  INTEGRATION  COREMODEL 
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3.3  Entity  and  Attribute  Glossary 


Entity  Name:  Area  Representation 

Entity  Number:  INT-42 


Entity  Definition:  The  symbolic  description  of  an  "Area  Shape  Element"  in  a 

"Geometric  Model". 


Business  Rules:  Eyery  "Area  Representation": 

• represents  one,  and  only  one,  "Area  Shape  Element". 

• must  be  one,  and  only  one,  of  the  following: 

"Brep  Area  Rep" 

"Facetted  Brep  Area  Rep" 

"SOLE  Edge  Area  Rep" 

"SOLE  Max  Area  Rep" 

"SOR  Edge  Area  Rep" 

"Partial  Rev  SOR  Max  Area  Rep" 

"Surface  Area  Rep" 

"UnstTuct  Geometry  Area  Rep" 

"Wireframe  Area  Rep" 


Primary  Key  Attributes: 

Shape  ID 
Shape  Elem  ID 
Area  Rep  ID 


Other  Attributes: 


(FK) 

(FK) 

The  means  of  distinguishing  each  "Area 
Representation"  from  all  the  others  for  the  same 
"Area  Shape  Element". 


Area  Rep  Type  The  means  of  determining  whether  an  "Area 

Representation"  is  a(n): 

"Brep  Area  Rep", 

"Facetted  Brep  Area  Rep", 

"SOLE  Edge  Area  Rep", 

"SOLE  Max  Area  Rep", 

"SOR  Edge  Area  Rep", 

"Partial  Rev  SOR  Max  Area  Rep", 

"Surface  Area  Rep", 

"Unstruct  Geometry  Area  Rep",  or 
"Wireframe  Area  Rep". 
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ENTITY  Area-Representation 
KEY 

Area-Shape-Element  "is  represented  by" 
Area-Rep-ID 
ENDK 

Area-Rep>-Type  NONXT-L 
ENDE 

EXPRESS: 

ENTITY  Area_Representation 

SUPERTYPE  OF  ( Brep_Area_Rep 


OR  Facetted_Brep_Area_Rep 
OR  SOLE_Edge_Area_Rep 
OR  SOLE_Max_Area_Rep 
OR  SOR_Edge_Area_Rep 
OR  Partial_Rev_SOR_Max_Area_Rep 
OR  Surface_Area_Rep 
OR  Unstruct_Geometry_Area_Rep 
OR  Wireframe_Area_Rep  ); 


END.ENTITY; 
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Entity  Name:  Area  Shape  Element 

Entity  Number:  INT-8 


Entity  Definition:  A "Dimensionality  2 Shape  Element"  that  is  arcwise  connected 

and  has  a uniform  underlying  mathematical  surface. 

Business  Rules:  Eyery  "Area  Shape  Element"; 

• is  a "Dimensionality  2 Shape  Element". 

• must  be  one,  and  only  one,  of  the  following; 

"Maximal  Area  Shape  Element" 

"Nonmaximal  Area  Shape  Element" 

• is  represented  by  zero,  one,  or  more  "Area 
Representations". 

Primary  Key  Attributes: 


Shape  ID 
Shape  Elem  ID 

Other  Attributes: 


Area  SE  Type 


(FK) 

(FK) 


The  means  of  determining  whether  an  "Area 
Shape  Element"  is  a(n): 

"Maximal  Area  Shape  Element"  or 
"Nonmaximal  Area  Shape  Element". 


SML: 


ENTITY  Area-Shape-Element 

CATEGORY  BY  Dim-2-SE-Type  OF  Dimensionality-2-Shape-Element 
Area-SE-Type  NONULL 
ENDE 

EXPRESS: 


ENTITY  Area_Shape_Element 

SUPERTYPE  OF  ( Maximal_Area_Shape_Element 

OR  Nonmaximal_Area_Shape-Element  ) 
SUBTYPE  OF  ( Dimensionality_2_Shape_Element  ); 
Representations  : LIST  OF  [ 0 : # ] OF  Area_Representation; 
END.ENTITY; 
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Entity  Name:  Boundary  Location  Shape  Element 


Entity  Number:  INT-21 

Entity  Definition:  A "Dimensionality  0 Shape  Element"  that  is  on  an  "Edge  Shape 
Element",  but  that  is  not  an  end  point. 


Business  Rules:  Eyery  "Boundary  Location  Shape  Element": 

• is  a "Dimensionality  0 Shape  Element". 

• is  represented  by  zero,  one,  or  more  "Partial  Rey  SOR 
Bdry  Loc  Reps". 


Primary  Key  Attributes: 

Shape  ID 

(FK) 

Shape  Elem  ID 

(FK) 

Other  Attributes: 

none 

SML: 

ENTITY  Boundary-Location-Shape-Element 

CATEGORY  BY  Dim-O-SE-Type  OF  Dimensionality-O-Shape-Element 
ENDE 

EXPRESS: 

ENTITY  Boundary_Location_Shape_Element 

SUBTYPE  OF  ( Dimensionality_0_Shape_Element  ); 
Representations  : LIST  OF  [ 0 : # ] OF  PartiaI_Rey_SOR_Bdry_Loc_Rep; 
END_ENTITY; 
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Entity  Name: 

Brep  Area  Rep 

Entity  Number: 

INT-43 

Entity  Definition: 

The  use  of  a "Face"  in  a "Manifold  Solid  Brep  Model"  to 
represent  an  "Area  Shap>e  Element".  In  a manifold  solid  Brep, 
face  represents  a portion  of  a solid’s  surface  area  that  (i)  has  a 
uniform  underlying  surface  and  (ii)  is  arcwise  connected.  If 
there  is  an  adjacent  face  with  the  same  underlying  surface,  the 
area  is  nonmaximal;  otherwise,  it  is  maximal. 

Business  Rules: 

Eyery  "Brep  Area  Rep": 

• is  an  "Area  Representation". 

• is  in  one,  and  only  one,  "Manifold  Solid  Brep  Model". 

• is  one,  and  only  one,  "Face". 

Primary  Key  Attributes: 

Shape  ID 

(FK) 

Shape  Elem  ID 

(FK) 

Area  Rep  ID 

(FK) 

Other  Attributes: 

Brep  Model  ID 

(FK) 

Face  ID 

(FK) 

SML: 


ENTITY  Brep- Area-Rep 

CATEGORY  BY  Area-Rep-Typ>e  OF  Area-Representation 
Face  "is  used  as"  NONULL 

Manifold-Solid-Brep-Model  "is  context  of  NONTJLL 
ENDE 

EXPRESS: 


ENTITY  Brep_Area_Rep 

SUBTYPE  OF  ( Area_Representation  ); 
Definition  : Face; 

Context  : Manifold_Solid_Brep_Model; 
END.ENTITV; 
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Entity  Name: 

Brep  Dim  0 SE  Rep 

Entity  Number: 

INT-85 

Entity  Definition: 

The  use  of  a "Vertex"  in  a "Manifold  Solid  Brep  Model"  to 
represent  a "Dimensionality  0 Shape  Element".  In  a manifold 
solid  Brep,  vertices  are  employed  in  maximal  faces,  nonmaximal 
faces,  subfaces,  and  vertex  loops.  In  the  first  three  cases,  the 
edges  that  meet  at  the  vertex  may  have  the  same  underlying 
curve.  So,  a vertex  may  represent  any  of  the  three  categories  of 
"Dimensionality  0 Shape  Element"  — corner,  boundary  location, 
or  interior  location. 

Business  Rules: 

Every  "Brep  Dim  0 SE  Rep": 

• is  a "Dim  0 Shape  Element  Representation". 

• is  in  one,  and  only  one,  "Manifold  Solid  Brep  Model". 

• is  one,  and  only  one,  "Vertex". 

Primary  Key  Attributes: 

Shape  ID 

(FK) 

Shape  Elem  ID 

(FK) 

Dim  0 Rep  ID 

(FK) 

Other  Attributes: 

Brep  Model  ID 

(FK) 

Vertex  ID 

(FK) 

SML: 


ENTITY  Brep-Dim-O-SE-Rep 

CATEGORY  BY  Dim-O-Rep-Type  OF  Dim-O-Shape-Element-Representation 
Vertex  "is  used  as"  NONULL 

Mardfold-Solid-Brep'Model  "is  context  of  NONULL 
ENTDE 

EXPRESS: 


ENTITY  Brep_Dim_0_SE_Rep 

SUBTYPE  OF  ( Dim_0_Shape_Element_Representation  ); 
Definition  : Vertex; 

Context  : Manifold_Solid_Brep_Model; 

END_ENTITY; 
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Entity  Name:  Brep  NM  Area  Rep 

Entity  Number:  INT-53 


Entity  Definition:  The  use  of  a "Subface"  in  a "Manifold  Solid  Brep  Model"  to 

represent  a "Nonmaximal  Area  Shape  Element".  In  a manifold 
solid  Brep,  a subface  represents  a portion  of  surface  area  that  is 
necessarily  nonmaximal  because  the  subface  is  a subset  of  a face 
with  a uniform  underlying  surface.  (Note:  The  IPIM  does  not 
require  that  a subface  ^ a prop>er  subset  of  the  containing  face, 
but  it  seems  pointless  to  haye  a subface  identical  to  its  containing 
face.  For  this  reason,  no  provision  is  made  here  for  representing 
a "Maximal  Area  Shape  Element"  with  a subface.) 


Business  Rules:  Eyery  "Brep  NM  Area  Rep": 

• is  a "Nonmaximal  Area  Representation". 

• is  in  one,  and  only  one,  "Manifold  Solid  Brep  Model". 

• is  one,  and  only  one,  "Subface". 


Primary  Key  Attributes: 


Shape  ID 

(FK) 

Shape  Elem  ID 

(FK) 

Nonmax  Area  Rep  ID 

(FK) 

Other  Attributes: 

Brep  Model  ID 

(FK) 

Subface  ID 

(FK) 

SML: 


ENTITY  Brep-NM-Area-Rep 

CATEGORY  BY  Nonmax-Area-Rep-Type 
OF  Nonmaximal- Area-Representation 
Subface  "is  used  as"  NONULL 
Manifold-Solid-Brep-Model  "is  context  of  NONULL 
ENDE 
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ENTITY  Brep_NM_Area_Rep 

SUBTYPE  OF  ( Nonmaximal_Area_Representation  ); 
Definition  : Subface; 

Context  : Manifold_Solid_Brep_Model; 

END_ENTITY; 
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Entity  Name: 
Entity  Number: 


SccUon  1:  INTEGRATION  CORE  MODEL 

Brep  Object  Rep 
INT-31 


Entity  Definition:  The  use  of  a "Manifold  Solid  Brep  Model"  to  represent  an 

"Object  Shape  Element".  A manifold  solid  Brep  represents  a 
volume  that  has  an  arcwise-connected  interior,  but  that  may 
include  voids. 


Business  Rules: 


Every  "Brep  Object  Rep": 

• is  an  "Object  Representation". 

• is  one,  and  only  one,  "Manifold  Solid  Brep  Model". 


Primary  Kev  Attributes: 

Shape  ID 
Shape  Elem  ID 
Object  Rep  ID 

Other  Attributes: 

Brep  Model  ID 
SML: 


(FK) 

(FK) 

(FK) 


(FK) 


ENTITY  Brep-Object'Rep 

CATEGORY  BY  Object-Rep-Type  OF  Object-Representation 
Manifold-Solid-Brep-Model  "is  used  as"  NONULL 
ENT)E 


EXPRESS: 


ENTITY  Brep_Object_Rep 

SUBTYPE  OF  ( Object_Representation  ); 
Definition  ; Manifold_Solid_Brep_Model; 
END.ENTITY; 
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Entity  Name:  Brep  Perimeter  Rep 

Entity  Number:  INT-74 


Entity  Definition:  The  use  of  a "Loop"  in  a "Manifold  SoUd  Brep  Model"  to 

represent  a "Perimeter  Shape  Element".  In  a manifold  solid 
Brep,  a loop  occurs  as  a boundary  of  a maximal  face.  Hence,  a 
loop  may  represent  the  perimeter  of  an  "Area  Shape  Element". 


Business  Rules:  Eyery  "Brep  Perimeter  Rep": 

• is  a "Perimeter  Representation". 

• b in  one,  and  only  one,  "Manifold  Solid  Brep  Model". 

• is  one,  2md  only  one,  "Loop". 


Primary  Key  Attributes: 


Shape  ID 

(FK) 

Shape  Elem  ID 

(FK) 

Perim  Rep  ID 

(FK) 

Other  Attributes: 

Brep  Model  ID 

(FK) 

Loop  ID 

(FK) 

SML: 

ENTITY  Brep-Perimeter-Rep 

CATEGORY  BY  Perim-Rep-Type  OF  Perimeter-Representation 
Loop  "is  used  as"  NOMJLL 

Manifold-Solid-Brep-Model  "is  context  of  NONULL 
ENDE 

EXPRESS: 

ENTITY  Brep_Perimeter_Rep 

SUBTYPE  OF  ( Perimeter_Representation  ); 

Definition  : Loop; 

Context  : Manifold_Solid_Brep_Model; 

END_ENTITY; 
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Entity  Name:  Brep  Seam  Rep 


Entity  Number:  INT-64 


Entity  Definition:  The  use  of  an  "Edge"  in  a "Manifold  Solid  Brep  Model"  to 

represent  a "Seam  Shape  Element".  In  a manifold  solid  Brep,  an 
edge  may  occur  as  a boundary  element  of  a maximal  or 
nonmaximal  face  and/or  as  an  edge  of  a subface  of  a maximal  or 
nonmaximal  face.  Even  if  the  parent  face  is  maximal,  the  edge 
may  be  nonmaximal;  i.e.,  the  edge  may  have  an  adjacent  edge 
with  the  same  underlying  curve.  Hence,  an  edge  may  represent 
a full  "natural"  edge,  a portion  of  a full  "natural"  edge,  or  a 
curve  in  the  interior  of  a "natural"  face.  So,  an  edge  may 
represent  any  of  the  three  categories  of  "Seam  Shape  Element"  -- 
edge,  subedge,  or  interior  seam. 


Business  Rules:  Every  "Brep  Seam  Rep": 

• is  a "Seam  Representation". 

• is  in  one,  and  only  one,  "Manifold  Solid  Brep  Model". 

• is  one,  and  only  one,  "Edge". 


Primary  Kev  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Seam  Rep  ID  (FK) 

Other  .Attributes: 

Brep  Model  ID  (FK) 

Edge  ID  (FK) 


SML: 


ENTITY  Brep>-Seam-Rep 

CATEGORY  BY  Seam-Rep-Type  OF  Seam-Representation 
Edge  "is  used  as"  NONULL 

Manifold-Solid-Brep-Model  "is  context  of  NONULL 
ENDE 
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EXPRESS: 


ISO  TC184/SC4/WG1 


SecUon  1:  INTEGRATION  CORE  MODEL 


(Draft  Proposal) 


ANNEX  D 


November  22,  1988  N2S8 


ENTITY  Brep_Seam_Rep 

SUBTYPE  OF  ( 5€am_Representation  ); 
Definition  : Edge; 

Context  : Manifold_Solid_Brep_Model; 
END_ENTTTY; 
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(Draft  Proposal) 

Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name:  Brep  Volume  Rep 

Entity  Number:  INT-35 


Entity  Definition:  The  use  of  a "Shell"  in  a "Manifold  Solid  Brep  Model"  to 

represent  a "Voidless  Volume  Shape  Element".  In  a manifold 
solid  Brep,  a shell  represents  a voidless  volume.  This  may  be 
the  peripheral  volume  of  the  represented  solid  or  a void  within 
the  solid. 


Business  Rules:  Every  "Brep  Volume  Rep": 

• is  a "Voidless  Volume  Representation". 

• is  in  one,  and  only  one,  "Manifold  Solid  Brep  Model". 

• is  one,  and  only  one,  "Shell". 

Primary  Kev  Attributes: 


Shape  ID 

(FK) 

Shape  Elem  ID 

(FK) 

Volume  Rep  ID 

(FK) 

Other  Attributes: 

Brep  Model  ID 

(FK) 

Shell  ID 

(FK) 

SML: 


ENTITY  Brep-Volume-Rep 

CATEGORY  BY  Volume-Rep-Type  OF  Voidless-Volume-Representation 
Shell  "is  used  as"  NONULL 

Manifold-Solid-Brep-Model  "is  context  of  NONULL 
ENT>E 

EXPRESS: 


ENTITY  Brep_Volume_Rep 

SUBTYPE  OF  ( Voidless_Volume_Representation  ); 
Definition  : Shell; 

Context  : Manifold_Solid_Brep_Model; 

END.ENTITY; 
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November  22,  1988 


Section  1:  INTEGRATION  CORE  MODEL 


M2S8 


Entity  Name:  Comer  Representation 


Entity  Number:  INT-91 

Entity  Definition:  The  symbolic  description  of  a "Comer  Shape  Element"  in  a 
"Geometric  Model". 


Business  Rules:  Every  "Corner  Representation": 

• represents  one,  and  only  one,  "Comer  Shape  Element". 

• must  be  one,  and  only  one,  of  the  following: 

"Full  Rey  SOR  Comer  Rep" 

"Partial  Rev  SOR  Corner  Rep" 


Primary  Kev  Attributes: 

Shape  ID 
Shape  Elem  ID 
Comer  Rep  ID 


Other  Attributes: 
Corner  Rep  Type 


(FK) 

(FK) 

The  means  of  distinguishing  each  "Corner 
Representation"  from  all  the  others  for  the  same 
"Comer  Shape  Element". 


The  means  of  determining  whether  a "Corner 
Representation"  is  a(n): 

"Full  Rev  SOR  Corner  Rep"  or 
"Partial  Rev  SOR  Comer  Rep". 


SML: 

ENTITY  Corner-Representation 
KEY 

Comer-Shape-Element  "is  represented  by" 
Corner-Rep-ID 
ENDK 

Corner-Rep-Type  NONULL 
ENTiE 

EXPRESS: 


ENTITY  Corner_Representation 

SUPERTYPE  OF  ( FulI_Rev_SOR_Corner_Rep 

OR  Partial_Rev_SOR_Corner_Rep  ); 

END_ENTITY; 
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ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


N2S8 


Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name:  Comer  Shape  Element 


Entity  Number:  INT-20 

Entity  Definition:  A "Dimensionality  0 Shape  Element"  that  is  the  intersection  of 
three  or  more  "Area  Shape  Elements"  or  that  is  the  apex  of  a 
cone-like  shape. 


Business  Rules:  Every  "Corner  Shape  Element": 

• is  a "Dimensionality  0 Shape  Element". 

• is  represented  by  zero,  one,  or  more  "Corner 
Representations". 

Primary  Kev  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Other  Attributes:  none 


SML: 


ENTITY  Comer-Shape-Element 

CATEGORY  BY  Dim-O-SE-Type  OF  Dimensionality-O-Shape-Element 
ENDE 

EXPRESS: 


ENTITY  Corner_Shape_Element 

SUBTYPE  OF  ( Dimensionality_0_Shape_Element  ); 
Representations  : LIST  OF  [ 0 : # ] OF  Corner_Representation; 
END_ENTITY; 
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(Draft  Proposal) 


November  22,  1988 


Section  1:  INTEGRATION  CORE  MODEL 


N2  8 8 


Entity  Name:  CSG  Primitive  Model 

Entity  Number:  GEO-84 


FnHtv  Definition:  Defined  in  the  PDES  Geometry  reference  model. 

Business  Rules:  Every  "CSG  Primitive  Model": 

• is  a "Geometric  Model". 

• is  used  as  zero,  one,  or  more  "CSG  Primitive  Volume 
Reps". 
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ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


Section  1:  INTEGRATION  CORE  MODEL 


1^2  3 8 


Entity  Name: 
Entity  Number: 

Entity  Definition: 

■.I—  -y— ■ . ■■  ■ ■ 


C5G  Primitiye  Volume  Rep 
INT-36 

The  use  of  a "CSG  Primitiye  Model"  to  represent  a "Voidless 
Volume  Shape  Element". 


Business  Rules:  Eyery  "CSG  Primitiye  Volume  Rep": 

• is  a "Voidless  Volume  Representation". 

• is  one,  and  only  one,  "CSG  Primitiye  Model". 


Primary  Key  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Volume  Rep  ID  (FK) 

Other  Attributes: 


CSG  Primitiye  Model  ID  (FK) 


SML: 

ENTITY  CSG-Primitiye-Volume-Rep 

CATEGORY  BY  Volume-Rep-Type  OF  Voidless-Volume-Representation 
CSG-Primitiye-Model  "is  used  as"  NONULL 
ENDE 


EXPRESS: 


ENTITY  CSG_Primitiye_Volume_Rep 

SUBTYPE  OF  ( Volume_Representation  ); 
Definition  : CSG_Primitive_Model; 
END_ENTITY; 
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ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


Section  1:  INTEGRATION  CORE  MODEL 


N2  8S 


Entity  Name: 
Entity  Number: 

Entity  Definition: 

Business  Rules: 


CSG  Solid  Dim  3 SE  Rep 
INT-26 

The  use  of  a ”CSG  Solid  Model"  to  represent  a "Dimensionality  3 
Shape  Element". 

Every  "CSG  Solid  Dim  3 SE  Rep": 

• is  a "Dim  3 Shape  Element  Representation". 

• is  one,  and  only  one,  "CSG  Solid  Model". 


Primary  Kev  Attributes: 


Shape  ID 

(FK) 

Shape  Elem  ID 

(FK) 

Dim  3 Rep  ID 

(FK) 

Other  Attributes: 

CSG  Solid  Model  ID  (FK) 


SML: 

ENTITY  CSG-Solid-Dim-3-SE-Rep 

CATEGORY  BY  Dim-3-Rep-Type  OF  Dim-3-Shape-Element'Representation 
CSG-Solid-Model  "is  used  as"  NONULL 
ENDE 


EXPRESS: 


ENTITY  CSG_Solid_Dim_3_SE_Rep 

SUBTYPE  OF  ( Dim_3_Shape_Element_Representation  ); 
Definition  : CSG_Solid_Model; 

END_ENTITY; 
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(Draft  Proposal) 


November  22,  1988 


N2  S S 


Entity  Name: 
Entity  Number: 

Entity  Definition: 

Business  Rules: 


Section  1:  INTEGRATION  CORE  MODEL 
CSG  Solid  Model 

GEO-85 

Defined  in  the  PDES  Geometry  reference  model. 

Every  "CSG  Solid  Model"; 

• is  a "Geometric  Model". 

• is  used  as  zero,  one,  or  more  "CSG  Solid  Dim  3 SE  Reps". 
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annex  D xj 

(Draft  Proposal)  November  22,  1988  K2  S 8 

Section  J.  integration  CORE  MODEL 


FnHtv  Name:  Dim  0 Shape  Element  Representation 

Entity  Number:  INT-84 

Entity  Definition:  The  symbolic  description  of  a "Dimensionality  0 Shape  Element" 
in  a "Geometric  Model". 


Business  Rules:  Every  "Dim  0 Shape  Element  Representation": 

• represents  one,  and  only  one,  "Dimensionality  0 Shape 
Element". 

• must  be  one,  and  only  one,  of  the  following: 

"Brep  Dim  0 SE  Rep" 

"Facetted  Brep  Dim  0 SE  Rep" 

"SOLE  Dim  0 SE  Rep" 

"Surface  Dim  0 SE  Rep" 

"Unstruct  Geometry  Dim  0 SE  Rep" 

"Wireframe  Dim  0 SE  Rep" 


Primary  Kev  Attributes: 

Shape  ID 
Shape  Elem  ID 
Dim  0 Rep  ID 


Other  Attributes: 


Dim  0 Rep  Type 


(FK) 

(FK) 

The  means  of  distinguishing  each  "Dim  0 Shape 
Element  Representation"  from  all  the  others  for  the 
same  "Dimensionality  0 Shape  Element". 


The  means  of  determining  whether  a "Dim  0 Shape 
Element  Representation"  is  a(n): 

"Brep  Dim  0 SE  Rep", 

"Facetted  Brep  Dim  0 SE  Rep", 

"SOLE  Dim  0 SE  Rep", 

"Surface  Dim  0 SE  Rep", 

"Unstruct  Geometry  Dim  0 SE  Rep",  or 
"Wireframe  Dim  0 SE  Rep". 
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ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


N288 


Section  1:  INTEGRATION  CORE  MODEL 


SML: 

ENTITY  Dim-O-Shape-Element-Representation 
KEY 

Dimensionality-O-Shape-Element  "is  represented  by" 
Dim-O-Rep-ID 
ENDK 

Dim-O-Rep-Type  NONULL 
ENDE 

EXPRESS: 

ENTITY  Dim_0_Shape_Element_Representation 
SUPERTYPE  OF  ( Brep_Dim_0_SE_Rep 

OR  Facetted_Brep_Dim_0_SE_Rep 
OR  SOLE_Dim_0_SE_Rep 
OR  Surface_Dim_0_SE_Rep 
OR  Unstruct_Geometry_Dim_0_SE_Rep 
OR  Wireframe_Dim_0_SE_Rep  ); 

END.ENTITY; 


Page  D3.1.1-54 


ISO  TC184/SC4/WG1 


Entity  Name: 


ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


Section  1:  INTEGRATION  CORE  MODEL 
Dim  3 Shape  Element  Representation 


N2S8 


Entity  Number:  INT-25 

Entit"/  Definition:  The  symbolic  description  of  a "Dimensionality  3 Shape  Element" 
in  a "Geometric  Model". 


Business  Rules:  Eyery  "Dim  3 Shape  Element  Representation": 

• represents  one,  and  only  one,  "Dimensionality  3 Shape 
Element". 

• must  be  one,  and  only  one,  of  the  following: 

"CSG  Solid  Dim  3 SE  Rep" 

"Surface  Dim  3 SE  Rep" 

"Unstruct  Geometry  Dim  3 SE  Rep" 

"Wireframe  Dim  3 SE  Rep" 


Primary  Key  Attributes: 

Shape  ID 
Shape  Elem  ID 
Dim  3 Rep  ID 


Other  Attributes: 


Dim  3 Rep  Type 


(FK) 

(FK) 

The  means  of  distinguishing  each  "Dim  3 Shape 
Element  Representation"  from  all  the  others  for  the 
same  "Dimensionality  3 Shape  Element". 


The  means  of  determining  whether  a "Dim  3 Shape 
Element  Representation"  is  a(n): 

"CSG  Solid  Dim  3 SE  Rep", 

"Surface  Dim  3 SE  Rep", 

"Unstruct  Geometry  l5im  3 SE  Rep",  or 
"Wireframe  Dim  3 SE  Rep". 


SML: 


ENTITY  Dim-3-Shape-EIement*Representation 
KEY 

Dimensionality-3-Shape-Element  "is  represented  by" 
Dim-3-Rep-ID 
ENDK 

Dini-3*Kep-Type  NONTJLL 
ENDE 
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EXPRESS: 

ENTITY  Dim_3. 
SUPERTYPE 


END.ENTITY; 


ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


Section  1:  INTEGRATION  CORE  MODEL 


Shape_Element_Representation 
OF  ( CSG_Solid_Dim_3_SE_Rep 
OR  Surface_Dim_3_SE_Rep 
OR  Unstruct_Geometry_Dim_3_SE_Rep 
OR  Wireframe_Dim_3_SE_Rep  ); 


N2c8 
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ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


N2S8 


Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name:  Dimensionality  0 Shape  Element 

Entity  Number:  INT-19 


Entity  Definition:  A "Shape  Element"  that  has  dimensionality  zero,  i.e.,  that  is  a 
location  on  the  surface  area  of  a shape. 

Business  Rules:  Every  "Dimensionality  0 Shape  Element": 

• is  a "Shape  Element". 

• must  be  one,  and  only  one,  of  the  following; 

"Boundary  Location  Shape  Element" 

"Comer  Shape  Element" 

"Interior  Location  Shape  Element" 

• is  represented  by  zero,  one,  or  more  "Dim  0 Shape 
Element  Representations". 


Primary  Key  Attributes: 


Shape  ID 
Shape  Elem  ID 

Other  Attributes: 

Dim  0 SE  Type 


(FK) 

(FK) 


The  means  of  determining  whether  a 
"Dimensionality  0 Shape  Element"  is  a(n); 
"Boundary  Location  Shape  Element", 
"Comer  Shape  Element",  or 
"Interior  Location  Shape  Element". 


SML: 


ENTITY  Dimensionality-O-Shape-Element 

CATEGORY  BY  Shape-Elem-Type  OF  Shape-Element 
Dim-O-SE-Type  NONULL 
ENDE 
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EXPRESS: 


ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


Section  I:  INTEGRATION  COREMODEL 


ENTITY  Dimensionality_0_S^ape_Element 
SUPERTYPE  OF  ( Corner_Shape_Element 

OR  Boundary_Location_Shape_Element 
OR  Interior  Location_Shape_Element  ) 
SUBTYPE  OF  ( Shape.Element  ); 

Representations  : LIST  OF  [ 0 : # ] OF 

Dim_0_Shape_Element_Representation; 

END.ENTITY; 


N288 


¥ 
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ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


N2S8 


Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name:  Dimensionality  1 Shape  Element 


Entity  Number:  INT-13 

Entity  Definition:  A "Shape  Element"  that  has  no  discontinuity  and  has 

dimensionality  one,  i.e.,  that  is  a path  on  the  surface  area  of  a 
shape. 


Business  Rules:  Eyery  "Dimensionality  1 Shape  Element": 

• is  a "Shape  Element". 

• must  be  one,  and  only  one,  of  the  following: 

"Perimeter  Shape  Element" 

"Seam  Shape  Element" 


Primary  Key  Attributes: 


Shape  ID 
Shape  Elem  ID 

Other  Attributes: 

Dim  1 SE  Type 


(FK) 

(FK) 


The  means  of  determining  whether  a 
"Dimensionality  1 Shape  Element"  is  a(n): 
"Perimeter  Shape  Element"  or 
"Seam  Shape  Element". 


SML: 


ENTITY  Dimensionality-l-Shape-Element 

CATEGORY  BY  Shape-Elem-Type  OF  Shape-Element 
Dim-l-SE"Type  NONULL 
ENDE 


EXPRESS: 


ENTITY  Dimensionality_l_Shape_Element 
SUPERTYPE  OF  ( S€am_Shape_Element 


SUBTYPE 

END_ENTITY; 


OR  P€rimeter_Shape_Element  ) 
OF  ( Shape_Element  ); 
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ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


N288 


Section  1:  INTEGRATION  CORE  MODEL 
Entity  Name:  Dimensionality  2 Shape  Element 

Entity  Number:  INT-7 


Entity  Definition:  A "Shape  Element"  that  has  dimensionality  two,  i.e.,  that  is  a 
portion  of  the  surface  area  of  a shap)€. 

Business  Rules:  Every  "Dimensionality  2 Shape  Element": 

• is  a "Shape  Element". 

• must  be  one,  and  only  one,  of  the  following: 

"Area  Shape  Element" 

"Zone  Shape  Element" 

• is  zero  or  one  "Form  Feature". 

• is  used  as  zero,  one,  or  more  "Zone  Shap>e  Element 
Components". 


Primary  Kev  Attributes: 

Shape  ID 
Shape  Elem  ID 

Other  Attributes: 

Dim  2 SE  Type 


(FK) 

(FK) 


The  means  of  determining  whether  a 
"Dimensionality  2 Shape  Element"  is  a(n): 
"Area  Shape  Element"  or 
"Zone  Shape  Element". 


SML: 


ENTITY  Dimensionality-2-Shape-Element 

CATEGORY  BY  Shape-Elem-Type  OF  Shape-Element 
Dim-2-SE-Type  NONULL 
ENDE 

EXPRESS: 


ENTITY  Diinensionality_2_Shape_Element 
SUPERTYPE  OF  ( Area_Shape_Element 
OR  Zone_Shape_Element  ) 

SUBTYPE  OF  ( Shape.Element  ); 

Form_Feature_Shape_Element  : OPTIONAL  Form_Feature; 
Use_As_Zone_Comp  : LIST  OF  [ 0 : # 1 Zone_Shap€_Element_Component; 
END_ENTITY; 


ISO  TC184/SC4/WG1 


November  22,  1988 


ANNEX  D 
(Draft  Proposal) 

Section  1:  INTEGRATION  CORE  MODEL 


N288 


Entity  Name:  EHmensionality  3 Shape  Element 


Entity  Number:  INT-3 

Entity  Definition:  A "Shape  Element"  that  has  dimensionality  three,  i.e.,  that  is  a 
volume. 

Business  Rules:  Every  "Dimensionality  3 Shape  Element": 

• is  a "Shape  Element". 

• must  be  one,  and  only  one,  of  the  following: 

"Object  Assembly  Shape  Element" 

"Object  Shape  Element" 

• is  represented  by  zero,  one,  or  more  "Dim  3 Shape 
Element  Representations". 


Primary  Kev  Attributes: 

Shape  ID 
Shape  Elem  ID 

Other  Attributes: 

Dim  3 SE  Type 


(FK) 

(FK) 


The  means  of  determining  whether  a 
"Dimensionality  3 Shape  Element"  is  a(n); 
"Object  Assembly  Shape  Element"  or 
"Object  Shape  Element". 


SML: 


ENTITY  Dimensionality-3-Shape-Element 

CATEGORY  BY  Shape-Elem-Type  OF  Shape-Element 
Dim-3-5E-Type  NONULL 
ENT»E 

EXPRESS: 


ENTITY  Dimensionality_3_Shape_Element 
SUPERTYPE  OF  ( Object_Shape_Element 

OR  Object_Assembly_Shape_Element  ) 
SUBTYPE  OF  ( Shape_Element  ); 

Representations  : LIST  OF  [ 0 : # ] OF 

Dim_3_Shape_Element_Representation; 

END.ENTITY; 
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ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


N2S8 


Enrirv’  Name: 
Entity  Number: 

Entity  Definition: 

Business  'Rules: 


Section  1:  INTEGRATION  CORE  MODEL 


TOP-3 

Defined  in  the  PDES  Topology  reference  model. 

Every  "Edge": 

• is  used  as  zero,  one,  or  more  "Brep  Seam  Reps". 

• is  used  as  zero,  one,  or  more  "SOLE  Edge  Area  Reps". 

• is  used  as  zero,  one,  or  more  "SOLE  Edge  NM  Area  Reps". 

• is  used  as  zero,  one,  or  more  "SOLE  Edge  Perimeter  Reps”. 

• is  used  as  zero,  one,  or  more  "SOLE  Edge  Seam  Reps". 

• is  used  as  zero,  one,  or  more  "SOR  Edge  Area  Reps". 

• is  used  as  zero,  one,  or  more  "SOR  Edge  NM  Area  Reps". 

• is  used  as  zero,  one,  or  more  "Partial  Rev  SOR  Edge 
Perimeter  Reps". 

• is  used  as  zero,  one,  or  more  "Partial  Rev  SOR  Edge  Seam 
Reps". 

• is  used  as  zero,  one,  or  more  "Surface  Seam  Reps". 

• is  used  as  zero,  one,  or  more  "Wireframe  Seam  Reps". 
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ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


N288 


Section  1:  INTEGRATION  CORE  MODEL 
Entity  Name:  Edge  Shape  Element 

Entity  Number:  INT-15 


Entity  Definition:  A "Seam  Shape  Element"  that  is  the  intersection  of  two 
"Maximal  Area  Shape  Elements".  Due  to  the  continuity 
requirement  on  "Dimensionality  1 Shape  Elements",  a "Seam 
Shape  Element"  does  not  haye  to  be  the  entire  intersection  of 
the  pair  of  "Maximal  Area  Shape  Elements",  but  it  must  be  a 
maximal  continuous  portion  of  their  intersection. 

Business  Rules:  Eyery  "Edge  Shap>€  Element"  is  a "Seam  Shape  Element". 


Primary  Key  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Other  Attributes:  none 


SML: 


ENTITY  Edge-Shape-Element 

CATEGORY  BY  Seam-SE-Type  OF  Seam-Shape-Element 
EXDE 


EXPRESS: 


ENTITY  Edge_Shape_Element 

SUBTYPE  OF  ( Seam_Shape_Element  ); 
END_ENTITY; 
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ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


N2S8 


Entity  Name: 
Entity  Number: 

Entity  Definition 

Business  Rules: 


Section  1:  INTEGRATION  CORE  MODEL 


Face 

TOP-5 

Defined  in  the  PDES  Topology  reference  model. 

Every  "Face": 

• is  the  face  revolved  by  zero,  one,  or  more  "Solid  of 
Revolution  Models". 

• is  bound  by  one  or  more  "Loop  Logical  Structures". 

• is  used  as  zero,  one,  or  more  "Brep  Area  Reps". 

• is  used  as  zero,  one,  or  more  "Facetted  Brep  Area  Reps". 

• is  used  as  zero,  one,  or  more  "Surface  Area  Reps". 


ISO  TC184/SC4/WG1 


ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


N2S8 


Section  1:  INTEGRATION  CORE  MODEL 
Entity  Name:  Facetted  Brep  Area  Rep 

Entity  Number:  INT-44 

Entity  Definition:  The  use  of  a "Face"  in  a "Facetted  Brep  Model"  to  represent  an 
"Area  Shape  Element". 

Business  Rules:  Every  "Facetted  Brep  Area  Rep": 


• is 

• is 

Primary  Kev  Attributes: 

in  one,  ai 
one,  and 

Shape  ID 

(FK) 

Shape  Elem  ID 

(FK) 

Area  Rep  ID 

(FK) 

Other  Attributes: 

Facetted  Brep  Model  ID 

(FK) 

Face  ID 

(FK) 

SML: 

ENTITY  Facetted-Brep- Area-Rep 

CATEGORY  BY  Area-Rep-Type  OF  Area-Representation 
Face  "is  used  as"  NONULL 
Facetted-Brep-Model  "is  context  of"  NONULL 
ENUE 

EXPRESS: 

ENTITY  Facetted_Brep_Area_Rep 

SUBTYPE  OF  ( Area_Representation  ); 
Definition  : Face; 

Context  : Facetted_Brep_Model; 

END.ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 
Entity  Name:  Facetted  Brep  Dim  0 SE  Rep 

Entity  Number:  INT-89 


Entity  Definition:  The  use  of  a "Point"  in  a "Facetted  Brep  Model"  to  represent  a 

"Dimensionality  0 Shape  Element". 

Business  Rules:  Every  "Facetted  Brep  Dim  0 SE  Rep": 

• is  a "Dim  0 Shape  Element  Representation". 

• is  in  one,  and  orJy  one,  "Facetted  Brep  Model". 

• is  one,  and  only  one,  "Point". 


Primary  Key  Attributes: 


Shape  ID 

(FK) 

Shape  Elem  ID 

(FK) 

Dim  0 Rep  ID 

(FK) 

Other  Attributes; 

Facetted  Brep  Model  ID 

(FK) 

Point  ID 

(FK) 

SML: 


ENTITY  Facetted-Brep-Dim-O-SE-Rep 

CATEGORY  BY  Dim-O-Rep-Type  OF  Dim-O-Shape-Element-Representation 
Point  "is  used  as"  NONULL 
Facetted-Brep-Model  "is  context  of"  NONULL 
ENDE 

EXPRESS: 


ENTITY  Facetted_Brep_Dim_0_SE_Rep 

SUBTYPE  OF  ( Dim_0_Shape_Element_Representation  ); 

Definition  : Point- 

Context  ; Facetted_Brep_Model; 

END.ENTITY; 
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Entity  Number.  GE086 

Entity  Definition:  Defined  in  the  PDES  Geometry  reference  model. 


Entity  Name:  Facetted  Brep  Model 
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Sectxon  1:  INTEGRATION  CORE  MODEL 


(Draft  Proposal) 


ANNEX  D 


November  22,  1988 


N2S8 


Business  Rules:  Every  "Facetted  Brep  Model": 


• is  a "Geometric  Model". 

• is  the  context  for  zero,  one,  or  more  "Facetted  Brep  Area 
Reps". 

• is  the  context  for  zero,  one,  or  more  "Facetted  Brep  Dim  0 
SE  Reps". 

• is  the  context  for  zero,  one,  or  more  "Facetted  Brep  NM 
Area  Reps". 

• is  used  as  zero,  one,  or  more  "Facetted  Brep  Object  Reps". 

• is  the  context  for  zero,  one,  or  more  "Facetted  Brep 
Perimeter  Reps". 

• is  the  context  of  zero,  one,  or  more  "Facetted  Brep 
Volume  Reps". 
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Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name: 


Facetted  Brep  NM  Area  Rep 


Entity  Number:  INT-54 

Entity  Definition:  The  use  of  a "Subface"  in  a "Facetted  Brep  Model"  to  represent  a 

"Nonmaximal  Area  Shape  Element". 


Business  Rules:  Every  "Facetted  Brep  NM  Area  Rep": 

• is  a "Nonmaximal  Area  Representation". 

• is  in  one,  and  only  one,  "Facetted  Brep  Model". 

• is  one,  and  only  one,  "Subface". 


Primary  Kev  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Nonmax  Area  Rep  ID  (FK) 

Other  Attributes: 

Facetted  Brep  Model  ID  (FK) 

Subface  ID  (FK) 


SML: 


ENTITY  Facetted-Brep-NM-Area-Rep 

CATEGORY  BY  Nonmax-Area-Rep-Type 
OF  Nonmaximal- Area-Representation 
Subface  "is  used  as"  NONULL 
Facetted-Brep-Model  "is  context  of"  NONULL 
ENDE 

EXPRESS: 


ENTITY  Facetted_Brep_NM_Area_Rep 

SUBTYPE  OF  ( Nonmaximal_Area_Representation  ); 
Definition  : Subface; 

Context  : Facetted_Brep_Model; 

END_ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 
Entirv^  Name:  Facetted  Brep  Object  Rep 

Entity  Number:  INT-32 

Entity  Definition:  The  use  of  a Tacetted  Brep  Model"  to  represent  an  "Object 
Shape  Element". 


Business  Rules:  Eyery  "Facetted  Brep  Object  Rep": 

• is  an  "Object  Representation". 

• is  one,  and  only  one,  "Facetted  Brep  Model". 


Primary  Key  Attributes: 

Shape  ID 

(FK) 

Shape  Elem  ID 

(FK) 

Object  Rep  ID 

(FK) 

Other  Attributes: 

Facetted  Brep  Model  ID 

(FK) 

SML: 


ENTITY  Facetted-Brep>-Object-Rep 

CATEGORY  BY  Object-Rep-Type  OF  Object-Representation 
Facetted-Brep>-Model  "is  used  as"  NONULL 
ENT)E 

EXPRESS: 


ENTITY  Facetted_Brep_Object_Rep 

SUBTYPE  OF  ( Object_Representation  ); 
Definition  : Facetted_Brep_Model; 
END.ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name:  Facetted  Brep  Perimeter  Rep 

Entity  Number:  INT-79 


Entity  Definition:  The  use  of  a Tolyloop"  in  a "Facetted  Brep  Model"  to  represent 

a "Perimeter  Shap>€  Element". 

Business  Rules:  Every  "Facetted  Brep  Perimeter  Rep": 

• is  a "Perimeter  Representation". 

• is  in  one,  and  only  one,  "Facetted  Brep  Model". 

• is  one,  and  only  one,  "Polyloop". 

Primary  Kev  Attributes: 


Shape  ID 

(FK) 

Shape  Elem  ID 

(FK) 

Perim  Rep  ID 

(FK) 

Other  Attributes: 

Facetted  Brep  Model  ID 

(FK) 

Polyloop  ID 

(FK) 

SML: 


ENTITY  Facetted-Brep-Perimeter-Rep 

CATEGORY  BY  Perim-Rep-Type  OF  Perimeter-Representation 
Polyloop  "is  used  as"  NONULL 
Facetted-Brep-Model  "is  context  of"  NONULL 
ENT)E 

EXPRESS: 


ENTITY  Facetted_Brep_Perimeter_Rep 

SUBTYPE  OF  ( Perimeter_Representation  ); 
Definition  : Polyloop; 

Context  : Facetted_Brep_Model; 

END_ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name: 

Facetted  Brep  Volume  Rep 

Entity  Number: 

INT-104 

Entity  Definition: 

The  use  of  a "Shell"  in  a "Facetted  Brep  Model"  to  represent 
"Voidless  Volume  Shape  Element". 

Business  Rules: 

Every  "Facetted  Brep  Volume  Rep": 

• is  a "Voidless  Volume  Representation". 

• is  in  one,  and  only  one,  "Facetted  Brep  Model". 

• is  one,  and  only  one,  "Shell". 

Primary  Key  Attributes: 

Shape  ID 

(FK) 

Shape  Elem  ID 

(FK) 

Volume  Rep  ID 

(FK) 

Other  Attributes: 

Facetted  Brep  Model  ID  (FK) 

Shell  ID 

(FK) 

SML: 


ENTITY  Facetted-Brep-Volume-Rep 

CATEGORY  BY  Volume-Rep-Type  OF  Voidless-Volume-Representation 
Shell  "is  used  as"  NONULL 
Facetted-Brep-Model  "is  context  of"  NONTJLL 
ENDE 

EXPRESS: 


ENTITY  Facetted_Brep_Volume_Rep 

SUBTYPE  OF  ( VoidIess_Volume_Representation  ); 
Definition  : Shell; 

Context  : Facetted_Brep_Model; 

END.ENTITY; 
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Name: 

Entity  Number: 

Entity  Definition: 

Business  Rules: 


Sectwn  1:  INTEGRATION  CORE  MODEL 


FEM 

FEM-1 

Defined  in  the  PDES  FEM  reference  model. 

Every  "FEM"  models  zero,  one,  or  more  "FEM  Product  Item 
Version  Definitions". 


ISO  TC184/SC4/WG1 


ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


N2  8 8 


Section  1:  INTEGRATION  CORE  MODEL 

Entitv  Name: 

FEIM  Product  Item  Version  Definition 

Entity  Number. 

FEM-2 

Entitv  Definition: 

Defined  in  the  PDES  FEM  reference  model. 

Business  Rules: 

Every  "FEM  Product  Item  Version  Definition": 

• is  modeled  by  one,  and  only  one,  "FEM". 

• models  one,  and  only  one,  "Product  Item  Version 
Functional  Definition". 
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SecUon  1:  INTEGRATION  CORE  MODEL 

Entity  Name: 

Form  Feature 

Entity  Number: 

FF-001 

Entity  Definition: 

Defined  in  the  PDES  Form  Feature  reference  model. 

Business  Rules; 

Eyery  "Form  Feature"  is  a "Dimensionality  2 Shape  Element" 
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Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name:  Full  Rev  SOR  Comer  Rep 


Entity  Number:  IN[T-92 


En^:tv  Definition:  The  use  of  a "Vertex"  in  a "Solid  of  Revolution  Model"  that  is 
revolved  through  360®  to  represent  a "Corner  Shape  Element". 

Business  Rules:  Every  "Full  Rev  SOR  Comer  Rep": 

• is  a "Corner  Representation". 

• is  in  one,  and  only  one,  "Solid  of  Revolution  Model". 

• is  one,  and  only  one,  "Vertex". 


Primary  Kev  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Comer  Rep  ID  (FK) 

Other  Attributes: 

SOR  Model  ID  (FK) 

Vertex  ID  (FK) 


SML: 


ENTITY  Full-Rev-SOR-Comer-Rep 

CATEGORY  BY  Corner-Rep-Type  OF  Corner-Representation 
Vertex  "is  used  as"  NONULL 
Solid-of-Revolution-Model  "is  context  of"  NONULL 
ENDE 

EXPRESS: 


ENTITY  Full_Rev_SOR_Corner_Rep 

SUBTYPE  OF  ( Corner_Representation  ); 
Definition  : Vertex; 

Context  : Solid_of_Revolution_Model; 
END.ENTITY; 


ISO  TC184/SC4/WG1  ANNEX  D November  22,  1988  N2  8 8 

(Draft  Proposal) 

Section  1:  INTEGRATION  CORE  MODEL 
Entity  Number:  INT-100 

Entity  Definition:  The  use  of  a "Vertex"  in  a "Solid  of  Revolution  Model"  that  is 
revolved  through  360®  to  represent  an  "Interior  Location  Shape 
Element". 


Business  Rules:  Every  "Full  Rev  SOR  Int  Loc  Rep": 

• is  a "Interior  Location  Representation". 

• is  in  one,  and  only  one,  "Solid  of  Revolution  Model". 

• is  one,  and  only  one,  "Vertex". 


Primary  Key  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Int  Loc  Rep  ID  (FK) 

Other  Attributes: 

SOR  Model  ID  (FK) 

Vertex  ID  (FK) 


SML: 

ENTITY  Full-Rev-SOR-Int-Loc-Rep 

CATEGORY  BY  Int-Loc-Rep-Type  OF  Interior-Location-Representation 
Vertex  "is  used  as"  NONULL 

Solid-of-Revolution-Model  "is  context  of"  NONULL 
ENTDE 


EXPRESS: 


ENTITY  Full_Rev_SORJnt_Loc_Rep 

SUBTYPE  OF  ( Interior_Location_Representation  ); 
Definition  : Vertex; 

Context  : Solid_of_Revolution_Model; 

END.ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 
Entity  Name:  Full  Rev  SOR  Object  Rep 

Entity  Number:  INT-33 

Entity  Definition:  The  use  of  a "Solid  of  Revolution  Model"  that  is  revolved 
through  360°  to  represent  an  "Object  Shape  Element". 


Business  Rules:  Every  "Full  Rev  SOR  Object  Rep": 

• is  an  "Object  Representation". 

• is  one,  and  only  one,  "Solid  of  Revolution  Model". 


Primary  Key  Attributes: 


Shape  ID 

(FK) 

Shape  Elem  ID 

(FK) 

Object  Rep  ID 

(FK) 

Other  Attributes: 

SOR  Model  ID  (FK) 


SML: 

ENTITY  Full-Rev-SOR-Object-Rep 

CATEGORY  BY  Object-Rep-Type  OF  Object-Representation 
Solid-of-Revolution-Model  "is  used  as"  NONULL 
ENTDE 

EXPRESS: 


ENTITY  FulLRev_SOR_Object_Rep 

SUBTYPE  OF  ( Object_Representation  ); 
Definition  : Solid_of_Revolution_Model; 
END.ENTITY; 
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Sectxon  1:  INTEGRATION  CORE  MODEL 

Entity  Name:  Full  Rev  SOR  Vertex  Perimeter  Rep 

Entity  Number:  INT-80 


Entity  Definition:  The  use  of  a "Vertex"  in  a complete  "Solid  of  Revolution 

Model"  that  is  revolved  through  360®  to  represent  a "Perimeter 
Shape  Element". 

Business  Rules:  Every  "Full  Rev  SOR  Vertex  Perimeter  Rep": 

• is  a "Perimeter  Representation". 

• is  in  one,  and  only  one,  "Solid  of  Revolution  Model". 

• is  one,  and  only  one,  "Vertex". 

Primary  Key  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Perim  Rep  ID  (FK) 

Other  Attributes: 

SOR  Model  ID  (FK) 

Vertex  ID  (FK) 


SML: 

ENTITY  Full-Re v-SOR- Vertex-Perimeter-Rep 

CATEGORY  BY  Perim-Rep-Type  OF  Perimeter-Representation 
Vertex  "is  used  as"  NONULL 

Solid-of-Revolution-Model  "is  context  of"  NONTJLL 
E.NDE 

EXPRESS: 


ENTITY  Full_Rev_SOR_Vertex_Perimeter_Rep 
SUBTYPE  OF  ( Perimeter_Representation  ); 
Definition  : Vertex; 

Context  : Solid_of_Revolution_Model; 
END_ENTITY; 


ISO  TC184/SC4/WG1 
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(Draft  Proposal) 
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Section  1:  INTEGRATION  CORE  MODEL 
Entity  Name:  Full  Rev  SOR  Volume  Rep 

Entity  Number:  INT-39 


Entity  Definition:  The  use  of  a "Loop  Logical  Structure"  in  a "Solid  of  Revolution 
Model"  that  is  revolved  through  360°  to  represent  a "Voidless 
Volume  Shap>e  Element". 

Business  Rules:  Every  "Full  Rev  SOR  Volume  Rep": 

• is  a "Voidless  Volume  Representation". 

• is  in  one,  and  only  one,  "^lid  of  Revolution  Model". 

• is  one,  and  only  one,  "Loop  Logical  Structure". 

Primary  Kev  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Volume  Rep  ID  (FK) 

Other  Attributes: 

SOR  Model  ID  (FK) 

Face  ID  (FK) 

Loop  ID  (FK) 


SML: 


ENTITY  Full-Rev-SOR-Volume-Rep 

CATEGORY  BY  Volume-Rep-Type  OF  Voidless-Volume-Representation 
Loop-Logical-Structure  "is  used  as"  (1)  NONTJLL 
Solid-of-Revolution-Model  "is  context  of"  (1)  NONULL 
ENDE 

EXPRESS: 

ENTITY  FuIl_Rev_SOR_Volume_Rep 

SUBTYPE  OF  ( Voidless_Volume_Representation  ); 

Definition  : Loop_Logical_Structure; 

Context  : Solid_of_Revolution_Model; 

END_ENTITY; 


Page  D3.1.1-79 


ISO  TC184/SC4/WG1 


ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


N288 


Entity  Name: 
Entity  Number: 

Entity  Definition 

Business  Rules: 


Section  1:  INTEGRATION  CORE  MODEL 
Geometric  Assembly  Model 
none 

Needs  to  be  defined  in  some  other  PDES  reference  model. 

Every  "Geometric  Assembly  Model" 

• is  a "Geometric  Model". 

• is  used  as  zero,  one,  or  more  "Object  Assembly 
Representations". 
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Section  1:  INTEGRATION  CORE  MODEL 

Entity  Name:  Geometric  Model 

Entity  Number:  INT-23 

Entity  Definition:  A formal  logical /mathematical  representation  of  a shape. 

Business  Rules:  Every  "Geometric  Model": 

• must  be  one,  and  only  one,  of  the  following: 

"CSG  Primitive  Model" 

"CSG  Solid  Model" 

"Facetted  Brep  Model" 

"Geometric  Assembly  Model" 

"Half  Space  Model" 

"Manifold  Solid  Brep  Model" 

"Solid  of  Linear  Extrusion  Model" 

"Solid  of  Revolution  Model" 

"Surface  Model" 

"Unstructured  Geometry  Model" 

"Wireframe  Model" 

• is  one  in  zero,  one,  or  more  "Pairs  of  Equivalent 
Geometric  Models". 

• is  the  other  in  zero,  one,  or  more  "Pairs  of  Equivalent 
Geometric  Models". 


Primary  Key  Attributes: 

Geom  Model  ID  The  means  of  distinguishing  each  "Geometric 

Model"  from  all  others. 

Other  Attributes: 

Geom  Model  Type  The  means  of  determining  whether  a "Geometric 

Model"  is  a(n): 

"CSG  Primitive  Model", 

"CSG  SoUd  Model", 

"Facetted  Brep  Model", 

"Geometric  Assembly  Model", 

"Half  Space  Model", 

"Manifold  Solid  Brep  Model", 

"Solid  of  Linear  Extrusion  Model", 

"Solid  of  Revolution  Model", 

"Surface  Model", 

'Ulnstructured  Geometry  Model",  or 
"Wireframe  Model". 
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SML: 


ENTITY  Geometric-Model 
KEY 

Geom-Model-ID 

ENDK 

Geom-Model-Type  NONULL 
ENT)E 

EXPRESS: 


N2  8 8 


ENTITY  Geometric_Model 

SUPERTYPE  OF  ( CSG_Primitive_Model 
OR  CSG.Solid.Model 
OR  Facetted_Brep_Model 
OR  Geometric_A3sembly_Model 
OR  Half_Space_Model 
OR  Manifold_Solid_Brep_Model 
OR  5olid_of_Linear_Extrusion_Model 
OR  Solid_of_Revolution_Model 
OR  Surface_Model 
OR  Unstructured_Geometry_Model 
OR  Wireframe_Model  ); 

END.ENTITY; 
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Entity  Name: 
Entity  Number: 

Entity  Definition: 

Buginess  Rules: 


SecUon  1:  INTEGRATION  CORE  MODEL 

Geometry 

GEO-1 

Defined  in  the  PDES  Geometry  reference  model. 

Every  "Geometry"; 

• is  used  as  zero,  one,  or  more  "Unstruct  Geometry  Area 
Reps". 

• is  used  as  zero,  one,  or  more  "Unstruct  Geometry  Dim  0 
SE  Reps". 

• is  used  as  zero,  one,  or  more  "Unstruct  Geometry  XM 
Area  Reps". 

• is  used  as  zero,  one,  or  more  "Unstruct  Geometry 
Perimeter  Reps". 

• is  used  as  zero,  one,  or  more  "Unstruct  Geometry  Seam 
Reps". 
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Business  Rules: 


ANNEX  D November  22,  1988  ^^2  8 8 

(Draft  Proposal) 

Section  1:  INTEGRATION  CORE  MODEL 
Half  Space  Model 

GEO-87 

Defined  in  the  PDES  Geometry  reference  model. 

Eyery  "Half  Space  Model": 

• is  a "Geometric  Model". 

• is  used  as  zero,  one,  or  more  "Half  Space  Volume  Reps". 
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SecUon  1:  INTEGRATION  CORE  MODEL 

Entity  Name:  Half  Space  Volume  Rep 

Entity  Number:  INT-37 

Entity  Definition:  The  use  of  a "Half  Space  Model"  to  represent  a "Voidless 
Volume  Shape  Element". 

Business  Rules:  Eyery  "Half  Space  Volume  Rep": 


• 

• 

Primary  Key  Attributes: 

is  a "Voidless  Volume  Representation", 
is  one,  emd  only  one,  "Half  Space  Model". 

Shape  ID 

Shape  Elem  ID 
Volume  Rep  ID 

Other  Attributes: 

(FK) 

(FK) 

(FK) 

Half  Space  Model  ID 

SML: 

(FK) 

ENTITY  Half-Space-Volume-Rep 

CATEGORY  BY  Volume-Rep-Type  OF  Voidless-Volume-Representation 
Half-Space-Model  "is  used  as"  NONULL 
ENDE 

EXPRESS: 

ENTITY  Half_Space_Volume_Rep 

SUBTYPE  OF  ( Voidless_Volume_Representation  ); 

Definition  : Half_Space_Model; 

END.ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 
Ngrp^c:  Interior  Location  Representation 


Entity  Number:  INT-99 


Entity  Definition:  The  symbolic  description  of  an  "Interior  Location  Shape 

Element"  in  a "Geometric  Model". 


Business  Rules:  Eyery  "Interior  Location  Representation": 

• represents  one,  and  only  one,  "Interior  Location  Shape 
Element". 

• must  be  one,  and  only  one,  of  the  following: 

"Full  Rev  SOR  Int  Loc  Rep" 

"Partial  Rev  SOR  Int  Loc  Rep" 


Primary  Kev  Attributes: 


Shape  ID 
Shape  Elem  ID 

Int  Loc  Rep  ID 


Other  Attributes: 

Int  Loc  Rep  Type 


(FK) 

(FK) 

The  means  of  distinguishing  each  "Interior 
Location  Representation"  from  all  the  others  for 
the  same  "Interior  Location  Shape  Element". 


The  means  of  determining  whether  an  "Interior 
Location  Representation"  is  a(n): 

"Full  Rev  SOR  Int  Loc  Rep"  or 
"Partial  Rev  SOR  Int  Loc  Rep". 


SML: 


ENTITY  Interior-Location-Representation 
KEY 

Interior-Location-Shape-Element  "is  represented  by" 
Int-Loc-Rep-ID 
ENDK 

Int-Loc-Rep-Type  NONULL 
ENDE 

EXPRESS' 


ENTITY  Interior_Location_Representation 

SUPERTYPE  OF  ( FulLRev_SOR_Int_Loc_Rep 

OR  Partial_Rev_SOR_Int_Loc_Rep  ); 

END.ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 


Entity  Xame:  Interior  Location  Shape  Element 

Entity  Number:  ENT-22 


Entity  Definition:  A "Dimensionality  0 Shape  Element"  that  is  in  the  interior  of  an 
"Area  Shap>e  Element". 

Business  Rules:  Every  "Interior  Location  Shape  Element": 

• is  a "Dimensionality  0 Shape  Element". 

• is  represented  by  zero,  one,  or  more  "Interior  Location 
Representations". 


Primary  Key  Attributes: 

Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Other  Attributes:  none 


SML: 


ENTITY  Interior-Location-Shape-Element 

CATEGORY  BY  Dim-O-SE-Type  OF  Dimensionality-O-Shape-Element 
ENDE 

EXPRESS: 


ENTITY  Interior_Location_Shape_Element 

SUBTYPE  OF  ( Dimensionality_0_Shape_Element  ); 
Representations  : LIST  OF  [ 0 : # ] OF  Interior_Location_Representation; 
END.ENTITY; 


ISO  TC1S4/SC4/WG1 


ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


N2  8 8 


Section  1:  INTEGRATION  CORE  MODEL 
Entity  Name:  Interior  Seam  Shape  Element 

Entity  Number:  INT-17 


Entity  Definition:  A "Seam  Shape  Element"  that,  with  the  pxDSsible  exception  of 
one  or  both  of  its  end  points,  lies  in  the  interior  of  an  "Area 
Shape  Element". 

Business  Rules:  Every  "Interior  Seam  Shape  Element"  is  a "Seam  Shape 
Element". 


Primary  Kev  Attributes: 

Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Other  Attributes:  none 


SML: 

ENTITY  Interior-Seam-Shape-Element 

CATEGORY  BY  Seam-SE-Type  OF  Seam-Shape-Element 
ENDE 

EXPRESS: 


ENTITY  Interior_Seam_Shape_Element 

SUBTYPE  OF  ( Seam_5hape_Element  ); 
END.ENTITY; 


ISO  TC184/SC4/WG1 


ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


N288 


Entity  Name: 
Entity  Number: 

Entity  Definition: 

Business  Rules: 


Section  1:  INTEGRATION  CORE  MODEL 


Loop 

TOP-4 

Defined  in  the  PDES  Topology  reference  model. 

Every  "Loop"; 

• bounds  zero,  one,  or  more  "Loop  Logical  Structures". 

• is  used  as  zero,  one,  or  more  "Brep  Perimeter  Reps". 

• is  used  as  zero,  one,  or  more  "SOLE  Loop  Perimeter  Reps’ 

• is  used  as  zero,  one,  or  more  "Partial  Rev  SOR  Loop 

Perimeter  Reps". 

• is  used  as  zero,  one,  or  more  "Surface  Perimeter  Reps". 

• is  used  as  zero,  one,  or  more  "Wireframe  Area  Reps". 

• is  used  as  zero,  one,  or  more  "Wireframe  NM  Area  Reps' 

• is  used  as  zero,  one,  or  more  'Wireframe  Perimeter 

Reps". 
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Entity  Xame: 
Entity  Number: 

Entity  Definition: 

Business  Rules: 


ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


Section  1:  INTEGRATION  CORE  MODEL 


N2 


Loop  Logical  Structure 
TOP-25 

Defined  in  the  PDES  Topology  reference  model. 

Every  "Loop  Logical  Structure": 

• is  used  as  zero,  one,  or  more  "Full  Rev  SOR  Volume 
Reps". 

• is  bound  by  one,  and  only  one,  "Loop". 

• bounds  one,  and  only  one,  "Face". 


ISO  TC184/SC4/WG1 


ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


N2S8 


Entity  Name: 
Entity  Number: 

Entity  Definition: 

Business  Rules: 


StcUon  1:  INTEGRATION  CORE  MODEL 


Manifold  Solid  Brep  Model 
GEO-88 

Defined  in  the  PDES  Geometiy  reference  model. 

Every  "Manifold  Solid  Brep  Model": 

• is  a "Geometric  Model". 

• is  the  context  of  zero,  one,  or  more  "Brep  Area  Reps". 

• is  the  context  of  zero,  one,  or  more  "Brep  Dim  0 SE  Reps". 

• is  the  context  of  zero,  one,  or  more  "Brep  NM  Area  Reps". 

• is  used  as  zero,  one,  or  more  "Brep  Object  Reps". 

• is  the  context  of  zero,  one,  or  more  "Brep  Perimeter  Reps". 

• is  the  context  of  zero,  one,  or  more  "Brep  Seam  Reps". 

• is  the  context  of  zero,  one,  or  more  "Brep  Volume  Reps". 
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SecUon  1:  INTEGRATION  CORE  MODEL 
Entity  Name:  Maximal  Area  Representation 

Entity  Number:  INT-105 

Entity  Definition:  The  symbolic  description  of  a "Maximal  Area  Shape  Element"  in 
a "Geometric  Model". 


Business  Rules:  Eyery  "Maximal  Area  Representation": 

• represents  one,  and  only  one,  "Maximal  Area  Shape 
Element". 

• must  be  one,  and  only  one,  of  the  following: 

"SOLE  Max  Area  Rep" 

"Partial  Rey  SOR  Max  Area  Rep" 


Primary  Key  Attributes: 

Shape  ID 
Shape  Elem  ID 
Max  Area  Rep  ID 


Other  Attributes: 


(FK) 

(FK) 

The  means  of  distinguishing  each  "Maximal  Area 
Representation"  from  all  the  others  for  the  same 
"Maximal  Area  Shape  Element". 


Maximal  Area  Rep  Type  The  means  of  determining  whether  a "Maximal 

Area  Representation"  is  a(n): 

"SOLE  Max  Area  Rep", 

"Partial  Rey  SOR  Max  Area  Rep", 


SML: 


ENTITY  Maximal-Area-Representation 
KEY 

Maximal-Area-Shape-Element  "is  represented  by" 
Max- Area-Rep- ID 
ENDK 

Max-Area-Rep-Type  NONULL 
ENDE 

EXPRESS: 


ENTITY  Maximal_Area_Representation 

SUPERTYTE  OF  ( SOLE_Max_Area_Rep 

OR  Partial_Rey_SOR_Max_Area_Rep  ); 

END_ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 
Entity  Name:  Maximal  Area  Shape  Element 

Entity  Number:  INT-9 


Entity'  Definition:  An  "Area  Shap>e  Element"  that  has  no  adjacent  "Area  Shape 
Element"  with  the  same  underlying  mathematical  surface. 

Business  Rules:  Every  "Maximal  Area  Shape  Element"  is  an  "Area  Shape 
Element". 


Primary  Kev  Attributes: 

Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Other  Attributes:  none 


SML: 


ENTITY  Maximal-Area-Shape-Element 

CATEGORY  BY  Area-SE-Type  OF  Area-Shape-Element 
ENDE 

EXPRESS: 


ENTITY  Maximal_Area_Shape_Element 

SUBTYPE  OF  ( Area_Shape_Element  ); 
END.ENTITY; 
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N2S8 


Enrir\’  Name:  Nonmaximal  Area  Representation 

Entity  Number:  INT-52 


Entity  Definition:  The  symbolic  description  of  a "Nonmaximal  Area  Shape 
Element"  in  a "Geometric  Model". 


Business  Rules:  Every  'TJonmaximal  Area  Representation"; 

• represents  one,  and  only  one,  "Nonmaximal  Area  Shape 
Element". 

• must  be  one,  and  only  one,  of  the  following: 

"Brep  NM  Area  Rep" 

"Facetted  Brep  NM  Area  Rep" 

"SOLE  Edge  NM  Area  Rep" 

"SOLE  Subface  NM  Area  Rep" 

"SOR  Edge  NM  Area  Rep" 

"Partial  Rev  SOR  Subface  NM  Area  Rep" 

"Surface  NM  Area  Rep" 

"Unstruct  Geometry  NM  Area  Rep" 

"Wireframe  NM  Area  Rep" 


Primary  Key  Attributes: 

Shape  ID 
Shape  Elem  ID 
Nonmax  Area  Rep  ID 


Other  Attributes: 


(FK) 

(FK) 

The  means  of  distinguishing  each  "Nonmaximal 
Area  Representation"  from  all  the  others  for  the 
same  "Nonmaximal  Area  Shape  Element". 


Nonmax  Area  Rep  Type  The  means  of  determining  whether  a 

"Nonmaximal  Area  Representation"  is  a(n): 
"Brep  NM  Area  Rep", 

"Facetted  Brep  NM  Area  Rep", 

"SOLE  Edge  NM  Area  Rep", 

"SOLE  Subface  NM  Area  Rep", 

"SOR  Edge  NM  Area  Rep", 

"Partial  Rev  SOR  Subface  NM  Area  Rep", 
"Surface  NM  Area  Rep", 

"Unstruct  Geometry  NM  Area  Rep",  or 
"Wireframe  NM  Area  Rep". 
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5ML: 


ENTITY  Nonmaximal-Area-Representation 
KEY 

Nonmaximal-Area-Shape-Element  "is  represented  by" 
Nonmax- Area-Rep-ID 
ENT>K 

Nonmax-Area-Rep-Type  NONULL 
ENDE 

EXPRESS: 


N288 


ENTITY  Nonmaximal_Area_Representation 
SUPERTYPE  OF  ( Brep_NM_Area_Rep 

OR  Facetted_Brep_NM_Area_Rep 
OR  SOLE_Edge_NM_Area_Rep 
OR  SOLE_Subface_NM_Area_Rep 
OR  SOR_Edge_NM_Area_Rep 
OR  Partial_Rev_SOR_Subface_NM_Area_Rep 
OR  Surface_NM_Area_Rep 
OR  Unstruct_Geometry_NM_Area_Rep 
OR  Wireframe_NM_Area_Rep  ); 

END_ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name:  Nonmaximal  Area  Shap)€  Element 

Entity  Number:  INT-10 


Entity  Definition:  An  "Area  Shape  Element"  that  has  at  least  one  adjacent  "Area 
Shape  Element"  with  the  same  underlying  mathematical 
surface. 


Business  Rules:  Every  "Nonmaximal  Area  Shape  Element": 

• is  an  "Area  Shape  Element". 

• is  represented  by  zero,  one,  or  more  "Nonmaximal  Area 
Representations". 

Primary  Key  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Other  Attributes:  none 


SML: 


ENTITY  Nonmaximal-Area-Shape-Element 

CATEGORY  BY  Area-SE-Type  OF  Area-Shap)e-Element 
ENT»E 

EXPRESS: 


ENTITY  Nonmaximal_Area_Shape_Element 
SUBTYPE  OF  ( Area_Shape_Element  ); 

Representations  : LIST  OF  [ 0 : # ] OF  Nonmaximal_Area_Representation; 
END.ENTITY; 
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Sechon  1:  INTEGRATION  CORE  MODEL 


Entity  Name:  Object  Assembly  Representation 

Entity  Number:  ENT-41 

Entity  Definition:  The  symbolic  description  of  an  "Object  Assembly  Shape 
Element"  in  a "Geometric  Model". 


Business  Rules:  Every  "Object  Assembly  Representation": 

• represents  one,  and  only  one,  "Object  Assembly  Shape 
Element". 

• is  one,  and  only  one,  "Geometric  Assembly  Model". 

Primary  Kev  Attributes: 

Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Obj  Assem  Rep  ID  The  means  of  distinguishing  each  "Object  Assembly 

Representation"  from  all  the  others  for  the  same 
"Object  Assembly  Shap>e  Element". 

Other  Attributes: 


Geom  Assem  Model  ID  (FK) 


SML: 

ENTITY  Object-Assembly-Representation 
KEY 

Object-Assembly-Shape-Element  "is  represented  by" 
Obj-Assem-Rep-ID 
ENT)K 

Geometric- Assembly-Model  "is  used  as"  NONTJLL 
ENTDE 


EXPRESS: 


ENTITY  Object_Assembly_Representation; 

Definition  ; GeometTic_Assembly_Model; 
END.ENTITY; 
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N2S8 


Entity  Name:  Object  Assembly  Shap>e  Element 

Entity  Number:  INT-6 


Entity  Definition:  A "Dimensionality  3 Shape  Element"  that  is  a collection  of  two 
or  more  p)ositioned  "Object  Shape  Elements". 

Business  Rules:  Every  "Object  Assembly  Shape  Element": 

• is  a "Dimensionality  3 Shape  Element". 

• is  represented  by  zero,  one,  or  more  "Object  Assembly 
Representations". 

Primary  Key  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Other  Attributes:  none 


SML: 


ENTITY  Object- Assembly-Shape-Element 

CATEGORY  BY  Dim-3-SE-Type  OF  Dimensionality-3-Shap>e-Element 
ENDE 

EXPRESS: 


ENTITY  Object_Assembly_Shape_Element 

SUBTYPE  OF  ( Dimensionality_3_Shape_Element  ); 
Representations  : LIST  OF  [ 0 : # ] OF  Object_Assembly_Representation; 
END_ENTITY; 
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Sectxon  1:  INTEGRATION  CORE  MODEL 
Entity  Name:  Object  Representation 

Entity  Number:  INT-30 


Entity  Definition:  The  symbolic  desaiption  of  an  "Object  Shape  Element"  in  a 
"Geometric  Model". 


Business  Rules:  Every  "Object  Representation": 

• represents  one,  and  only  one,  "Object  Shape  Element". 

• must  be  one,  and  only  one,  of  the  following: 

"Brep  Object  Rep" 

"Full  Rev  SOR  Object  Rep" 

"Facetted  Brep  Object  Rep" 


Primary  Kev  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Object  Rep  ID  The  means  of  distinguishing  each  "Object 

Representation"  from  all  the  others  for  the  same 
"Object  Shape  Element". 

Other  Attributes: 

Object  Rep  Type  The  means  of  determining  whether  an  "Object 

Representation"  is  a(n): 

"Brep  Object  Rep", 

"Full  Rev  SOR  Object  Rep",  or 
"Facetted  Brep  Object  Rep". 


SML: 


ENTITY  Object-Representation 
KEY 

Object-Shape-Element  "is  represented  by" 
Object-Rep-ID 
ENDK 

Object-Rep-Type  NONULL 
ENT»E 
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EXPRESS: 

ENTITY  Object_Representation 

SUPERTYPE  OF  ( Brep_Object_Rep 

OR  Full_Rev_SOR_Object_Rep 
OR  Facetted_Brep_Object_Rep  ); 

END.ENTITY; 


N2S8 
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(Draft  Proposal) 
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Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name:  Object  Shape  Element 

Entity  Number:  INT-4 


Entity  Definition:  A "Dimensionality  3 Shape  Element"  that  is  arcwise  connected. 
It  may  haye  interior  voids. 

Business  Rules:  Every  "Object  Shape  Element": 

• is  a "Dimensionality  3 Shape  Element". 

• is  zero  or  one  "Voidless  Volume  Shape  Element". 

• is  represented  by  zero,  one,  or  more  "Object 
Representations". 

Primary  Kev  Attributes: 


Shape  ID 
Shape  Elem  ID 

Other  Attributes: 

Object  SE  Type 


(FK) 

(FK) 


The  means  of  determining  whether  an  "Object 
Shape  Element"  is  a "Voidless  Volume  Shape 
Element"  or  not. 


SML: 

ENTITY  Object-Shape-Element 

CATEGORY  BY  Dim-3-SE-Type  OF  Dimensionality-3-Shape-Element 
Object-SE-Type 
ENDE 

EXPRESS: 

ENTITY  Object_Shape_Element 

SUBTYPE  OF  ( Dimensionality_3_Shape_Element  ); 
Voidless_Volume  : OPTIONAL  Voidless_Volume_Shape_Element; 
Representations  : LIST  OF  [ 0 : # ] OF  Object_Representation; 
END_ENTITY; 
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(Draft  Proposal) 
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Section  1:  INTEGRATION  CORE  MODEL 


Name:  Pair  of  Equivalent  Geometric  Models 

Entity  Number:  INT-24 


Entity  Definition:  Identifies  alternative  representations  of  shape. 

Business  Rules:  Every  "Pair  of  Equivalent  Geometric  Models": 

• includes  one,  and  only  one,  first  "Geometric  Model". 

• includes  one,  and  only  one,  second  "Geometric  Model". 


Primary  Kev  Attributes: 


Geom  Model  1 ID 


Geom  Model  2 ID 


Other  Attributes: 


(FK)  - The  role  name  for  the  Geom  Model  ID  of 
one  "Geometric  Model"  in  the  pair  of  equivalent 
models. 

(FK)  - The  role  name  for  the  Geom  Model  ID  of  the 
other  "Geometric  Model"  in  the  pair  of  equivalent 
models. 

none 


SML: 

ENTITY  Pair-of-Equivalent-Geometric-Models 
KEY 

Geometric-Model  "is  one  in" 

ROLE  Geom-Model-l-ID  FOR  Geom-Model-ID 
Geometric-Model  "is  other  in" 

ROLE  Geom-Model-2-ID  FOR  Geom-Model-ID 

ENDK 

ENDE 


EXPRESS: 


ENTITY  Pair_of_Equivalent_Geometric_Models; 
First_Model  : Geometric_Model; 
Second_Model  : Geometric_Model; 
END.ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 


N2S8 


Entity  Name:  Partial  Rev  SOR  Bdry  Loc  Rep 


Entity  Number.  INT-97 

Entity  Definition:  The  use  of  a "Vertex"  in  a "Solid  of  Revolution  Model"  that  is 

revolved  through  less  than  360°  to  represent  a "Boundary 
Location  Shape  Element". 


Business  Rules:  Every  "Partial  Rev  SOR  Bdry  Loc  Rep": 

• represents  one,  and  only  one,  "Boundary  Location  Shape 
Element". 

• is  in  one,  and  only  one,  "Solid  of  Revolution  Model". 

• is  one,  and  only  one,  "Vertex". 


Primary  Key  Attributes: 


Shape  ID 

(FK) 

Shape  Elem  ID 

(FK) 

Bdry  Loc  Rep  ID 

(FK) 

Other  Attributes: 

SOR  Model  ID 

(FK) 

Vertex  ID 

(FK) 

Bdry  Loc  Start  or  End  Face  Indicates  whether  the  "Partial  Rev  SOR  Bdry  Loc 

Rep"  is  on  the  starting  or  ending  face  in  the 
partially  revolved  "Solid  of  Revolution  Model". 


SML: 

ENTITY  Partial-Rev-SOR-Bdry-Loc-Rep 
KEY 

Boundary-Location-Shape-Element  "is  represented  by" 
Bdry-Loc-Rep-ID 
ENDK 

Vertex  "is  used  as"  NONTJLL 

Solid-of-Revolution-Model  "is  context  of"  NONTJLL 
Bdry-Loc-Start-or-End-Face  NONULL 
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ANNEX  D 
(Draft  Proposal) 
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Section  1:  INTEGRATION  CORE  MODEL 


EXPRESS: 

TYPE 

Partial_Rev_SOR_Face_Types  = 

ENUMERATION  OF  ( Starting_SOR_Face,  Ending_SOR_Face  ); 
END_TYPE; 

ENTITY  Parti al_Rev_SOR_Bdry _Loc_Rep; 

Definition  : Vertex; 

Context  : Solid_of_Revolution_Model; 

Face  : Partial_Rev_SOR_Face_Types; 

END.ENTITY; 
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ANNEX  D 
(Draft  Proposal) 
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SecUon  1:  INTEGRATION  CORE  MODEL 


Name:  Partial  Rev  SOR  Comer  Rep 

Entity  Number  INT-93 


Entity  Definition:  The  use  of  a "Vertex"  in  a "Solid  of  Revolution  Model"  that  is 
revolved  through  less  than  360°  to  represent  a "Comer  Shape 
Element". 


Business  Rules:  Every  "Partial  Rev  SOR  Corner  Rep": 

• is  a "Comer  Representation". 

• is  in  one,  and  only  one,  "Solid  of  Revolution  Model". 

• is  one,  and  only  one,  "Vertex". 


Primary  Key  Attributes: 

Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Comer  Rep  ID  (FK) 

Other  Attributes: 


SOR  Model  ID 
Vertex  ID 

Comer  Start  or  End  Face 


(FK) 

(FK) 

Indicates  whether  the  "Partial  Rev  SOR  Comer 
Rep"  is  on  the  starting  or  ending  face  in  the 
partially  revolved  "Solid  of  Revolution  Model". 


SML: 


ENTITY  Partial-Rev-SOR-Corner-Rep 

CATEGORY  BY  Corner-Rep-Type  OF  Corner-Representation 
Vertex  "is  used  as"  NONULL 
Solid-of-Revolution-Model  "is  context  of"  NONULL 
Comer-Start-or-End-Face  NONULL 
ENDE 

EXPRESS: 


ENTITY  Partial_Rev_SOR_Corner_Rep 

SUBTYPE  OF  ( Comer_Representation  ); 
Definition  : Vertex; 

Context  : Solid_of_Revolution_Model; 

Face  : Partial  Rev_SOR_Face_Types; 
END_ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 


Name:  Partial  Rev  SOR  Edge  Perimeter  Rep 

Entity  Number:  INT-81 


Entity  Definition:  The  use  of  an  "Edge"  in  a "Solid  of  Revolution  Model"  that  is 

revolved  through  less  than  360®  to  represent  a "Perimeter  Shape 
Element". 


Business  Rules:  Every  "Partial  Rev  SOR  Edge  Perimeter  Rep": 

• is  a "Perimeter  Representation". 

• is  in  one,  and  only  one,  "Solid  of  Revolution  Model". 

• is  one,  and  only  one,  "Edge". 

Primary  Kev  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Perim  Rep  ID  (FK) 

Other  Attributes: 

SOR  Model  ID  (FK) 

Edge  ID  (FK) 


SML: 


ENTITY  Partial-Rev*SOR-Edge-Perimeter-Rep 

CATEGORY  BY  Perim-Rep-Type  OF  Perimeter-Representation 
Edge  "is  used  as"  NONULL 

Solid-of-Revolution-Model  "is  context  of"  NONULL 
ENT)E 

EXPRESS: 


ENTITY  Partial_Rev_SOR_Edge_Perimeter_Rep 
SUBTYPE  OF  ( Perimeter_Representation  ); 
Definition  : Edge; 

Context  : Solid_of_Revolution_Model; 
END.ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 
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Entity  Name:  Partial  Rev  SOR  Edge  Seam  Rep 

Entity  Number:  INT-67 


Entity  Definition:  The  use  of  an  "Edge"  in  a "Solid  of  Revolution  Model"  that  is 
revolved  through  less  than  360®  to  represent  a "Seam  Shape 
Element". 


Business  Rules:  Every  "Partial  Rev  SOR  Edge  Seam  Rep": 

• is  a "Seam  Representation". 

• is  in  one,  and  only  one,  "Solid  of  Revolution  Model". 

• is  one,  and  only  one,  "Edge". 


Primary  Kev  Attributes: 


Shape  ID 

(FK) 

Shape  Elem  ED 

(FK) 

Seam  Rep  ID 

(FK) 

Other  Attributes: 

SOR  Model  ID 

(FK) 

Edge  ID 

SOR  Seam  Start  or 

(FK) 

End  Face  Indicates  whether  the  "Partial  Rev  SOR  Edge  Seam 

Rep"  is  on  the  starting  or  ending  face  in  the 
partially  revolved  "Solid  of  Revolution  Model". 


SML: 

ENTITY  Partial-Rev-SOR-Edge-Seam-Rep 

CATEGORY  BY  Seam-Rep-Type  OF  ^am-Representation 
Edge  "is  used  as"  NONULL 

Solid-of-Revolution-Model  "is  context  of"  NONULL 
SOR-Seam-Start-or-End-Face  NONULL 
ENUE 

EXPRESS: 

ENTITY  Partial_Rev_SOR_Edge_Seam_Rep 
SUBPlTE  OF  ( Seam.Representation  ); 

Definition  : Edge; 

Context  : Solid_of_Revolution_Model; 

Face  : Partial_Rev_SOR_Face_Types; 

END_ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 
Entity  Name:  l^artial  Rev  SOR  Int  Loc  Rep 

Entity  Number:  INT-101 


Entity  Definition:  The  use  of  a "Vertex"  in  a "Solid  of  Revolution  Model"  that  is 
revolved  through  less  than  360®  to  represent  an  "Interior 
Location  Shape  Element". 


Business  Rules: 


Every  "Partial  Rev  SOR  Int  Loc  Rep": 

• is  a "Interior  Location  Representation". 

• is  in  one,  and  only  one,  "Solid  of  Revolution  Model". 

• is  one,  and  only  one,  "Vertex". 


Primary  Kev  Attributes: 


Shape  ID 
Shape  Elem  ID 
Int  Loc  Rep  ID 


(FK) 

(FK) 

(FK) 


Other  Attributes: 


SOR  Model  ID 
Vertex  ID 

Int  Loc  Start  or  End  Face 


(FK) 

(FK) 

Indicates  whether  the  "Partial  Rev  SOR  Int  Loc 
Rep"  is  on  the  starting  or  ending  face  in  the 
partially  revolved  "Solid  of  Revolution  Model". 


SML: 


ENTITY  Partial-Rev-SOR-Int-Loc-Rep 

CATEGORY  BY  Int-Loc-Rep-Type  OF  Interior-Location-Representation 
Vertex  "is  used  as"  NONULL 

Solid-of-Revolution-Model  "is  context  of"  NONULL 
Int-Loc-Start-or-End-Face  NONULL 
ENDE 

EXPRESS: 


ENTITY  Partial_Rev_SORJnt_Loc_Rep 

SUBTYPE  OF  ( Interior_Location_Representation  ); 
Definition  : Vertex; 

Context  : Solid_of_Revolution_Model; 

Face  : Partial_Rev_SOR_Face_Types; 

END_ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name:  Partial  Rev  SOR  Loop  Perimeter  Rep 

Entity  Number:  INT-77 


Entity  Definition:  The  use  of  a "Loop"  in  a "Solid  of  Revolution  Model"  that  is 

revolved  through  less  than  360°  to  represent  a "Perimeter  Shape 
Element". 


Business  Rules:  Every  Tartial  Rev  SOR  Loop  Perimeter  Rep"; 

• is  a "Perimeter  Representation". 

• is  in  one,  and  only  one,  "Solid  of  Revolution  Model". 

• is  one,  and  only  one,  "Loop". 


Primary  Key  Attributes: 


Shape  ID 

(FK) 

Shape  Elem  ID 

(FK) 

Perim  Rep  ID 

(FK) 

Other  Attributes: 

SOR  Model  ID 

(FK) 

Loop  ID 

SOR  Perim  Start  or 

(FK) 

End  Face 

Indicates  whether  the  "Partial  Rev  SOR  Loop 
Perimeter  Rep"  is  on  the  starting  or  ending  face 
the  partially  revolved  "Solid  of  Revolution 

Model". 


SML: 


ENTITY  Partial-Rev-SOR-Loop-Perimeter-Rep 

CATEGORY  BY  Perim-Rep-Type  OF  Perimeter-Representation 
Loop  "is  used  as"  NONLILL 

Solid-of-Revolution-Model  "is  context  of  NONULL 
SOR-Perim-Start-or-End-Face  NONULL 
ENDE 
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EXPRESS: 

ENTITY  Partial_Rev_SOR_Loop_Perimeter_Rep 
SUBTYPE  OF  ( Periineter_Representation  ); 
Definition  : Loop; 

Context  : Solid_of_Revolution_Model; 

Face  : Partial_Rev_SOR_Face_Types; 
END.ENTITY; 


N288 
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Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name:  Partial  Rev  SOR  Max  Area  Rep 

Entity  Number:  INT-46 


Entity  Definition:  The  use  of  a "Solid  of  Revolution  Model"  that  is  revolved 
through  less  than  360°  to  represent  a "Maximal  Area  Shape 
Element". 


Business  Rules:  Every  "Partial  Rev  SOR  Max  Area  Rep": 

• is  an  "Maximal  Area  Representation". 

• is  one,  and  only  one,  "Solid  of  Revolution  Model". 

Primary  Key  Attributes: 


Shape  ID 
Shape  Elem  ID 
Area  Rep  ID 

Other  Attributes: 


SOR  Model  ID 
SOR  Max  Area  Start  or 
End  Face 


(FK) 

(FK) 

(FK) 


(FK) 

Indicates  whether  the  "Partial  Rev  SOR  Max  Area 
Rep"  is  on  the  starting  or  ending  face  in  the 
partially  revolved  "Solid  of  Revolution  Model". 


SML: 


ENTITY  Partial-Rev-SOR-Max-Area-Rep 

CATEGORY  BY  Max-Area-Rep-Type  OF  Maximal-Area-Representation 
Solid-of-Revolution-Model  "is  used  as"  NONULL 
SOR-Max-Area-Start-or-End-Face  NONULL 
ENDE 

EXPRESS: 

ENTITY  Partial_Rev_SOR_Max_Area_Rep 

SUBTYPE  OF  ( Maximal_Area_Representation  ); 

Definition  : Solid_of_Revolution_Model; 

Face  : Partial_Rev_SOR_Face_Types; 

END.ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name:  Partial  Rev  SOR  Subface  NM  Area  Rep 

Entity  Number:  INT-56 


Entity  Definition:  The  use  of  a "Subface”  in  a "Solid  of  Revolution  Model"  that  is 
revolved  through  less  than  360°  to  represent  a "Nonmaximal 
Area  Shape  Element". 

Business  Rules:  Every  "Partial  Rev  SOR  Subface  NM  Area  Rep": 

• is  a "Nonmaximal  Area  Representation". 

• is  in  one,  emd  only  one,  "Solid  of  Revolution  Model". 

• is  one,  and  only  one,  "Subface". 


Primary  Key  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Nonmax  Area  Rep  ID  (FK) 

Other  Attributes: 


SOR  Model  ID 
Subface  ID 

SOR  Nonmax  Area  Start 
or  End  Face 


(FK) 

(FK) 

Indicates  whether  the  "Partial  Rev  SOR  Subface 
NM  Area  Rep"  is  on  the  starting  or  ending  face  in 
the  partially  revolved  "Solid  of  Revolution 
Model". 


SML: 


ENTITY  Partial-Rev-SOR-Subface-NM-Area-Rep 
CATEGORY  BY  Nonmax-Area-Rep-Type 
OF  Nonmaximal-Area-Representation 
Subface  "is  used  as"  NONULL 
Solid-of-Revolution-Model  "is  context  of"  NONULL 
SOR-Nonmax-Area-Start-or-End-Face  NONULL 
ENDE 
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EXPRESS: 


ENTITY  Partial_Rev_SOR_Subface_NM_Area_Rep 

SUBTYPE  OF  ( Nonmaximal_Area_Representation  ); 
Definition  : Subface; 

Context  : Solid_of_Revolution_Model; 

Face  ; Partial_Rev_SOR_Face_Types; 

END_ENTITY; 


N288 
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Section  1:  INTEGRATION  CORE  MODEL 
Entity  Name:  Partial  Rev  SOR  Volume  Rep 

Entity  Number:  INT-38 

Entity  Definition:  The  use  of  a "Solid  of  Revolution  Model"  that  is  revolved 

through  less  than  360°  to  represent  a "Voidless  Volume  Shape 
Element". 


Business  Rules:  Every  "Partial  Rev  SOR  Volume  Rep": 

• is  a "Voidless  Volume  Representation". 

• is  one,  and  only  one,  "Solid  of  Revolution  Model". 


Primary  Key  Attributes: 


Shape  ID 

(FK) 

Shape  Elem  ID 

(FK) 

Volume  Rep  ID 

(FK) 

Other  Attributes: 

SOR  Model  ID 

(FK) 

SML: 

ENTITY  Partial-Rev-SOR-Volume-Rep 

CATEGORY  BY  Volume-Rep-Type  OF  Voidless-Volume-Representation 
Solid-of-Revolution-Model  "is  used  as"  NONULL 
ENT)E 

EXPRESS: 


ENTITY  Parti al_Rev_SOR_Volume_Rep 

SUBTYPE  OF  ( Voidless_Volume_Representation  ); 
Definition  : Solid_of_Revolution_Model; 

END.ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 
Entity  Name:  Perimeter  Representation 

Entity  Number:  INT-73 


Entity  Definition:  The  symbolic  description  of  a "Perimeter  Shape  Element"  in  a 
"Geometric  Model". 


Business  Rules:  Eyery  "Perimeter  Representation": 

• represents  one,  and  only  one,  "Perimeter  Shape  Element". 

• must  be  one,  and  only  one,  of  the  following: 

"Brep  Perimeter  Rep" 

"Facetted  Brep  Perimeter  Rep" 

"SOLE  Edge  Perimeter  Rep" 

"SOLE  Loop  Perimeter  Rep" 

"Partial  Rev  SOR  Edge  Perimeter  Rep" 

"Partial  Rev  SOR  Loop  Perimeter  Rep" 

"Full  Rev  SOR  Vertex  Perimeter  Rep" 

"Surface  Perimeter  Rep" 

"Unstruct  Geometry  Perimeter  Rep" 

"Wireframe  Perimeter  Rep" 


Primary  Kev  Attributes: 

Shape  ID 
Shape  Elem  ID 
Perim  Rep  ID 


Other  Attributes: 


Perim  Rep  Type 


(FK) 

(FK) 

The  means  of  distinguishing  each  "Perimeter 
Representation"  from  all  the  others  for  the  same 
"Perimeter  Shape  Element". 


The  means  of  determining  whether  a 'Perimeter 
Representation"  is  a(n): 

"Brep  Perimeter  Rep", 

"Facetted  Brep  Perimeter  Rep", 

"SOLE  Edge  Perimeter  Rep", 

"SOLE  Loop  Perimeter  Rep", 

"Partial  Rev  SOR  Edge  Perimeter  Rep", 
"Partial  Rev  SOR  Loop  Perimeter  Rep", 

"Full  Rev  SOR  Vertex  Perimeter  Rep", 
"Surface  Perimeter  Rep", 

"Unstruct  Geometry  Perimeter  Rep",  or 
"Wireframe  Perimeter  Rep". 
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SML: 

ENTITY  Perimeter-Representation 
KEY 

Perimeter-Shape-Element  "is  represented  by" 

Perim-Rep-ID 

ENDK 

Perim-Rep-Type  NONULL 
ENTDE 

EXPRESS: 


ENTITY  Perimeter_Representation 

SUPERTYPE  OF  ( Brep_Perimeter_Rep 

OR  Facetted_Brep_Perimeter_Rep 
OR  SOLE_Edge_Perimeter_Rep 
OR  SOLE_Loop_Perimeter_Rep 
OR  Partial_Rev_SOR_Edge_Perimeter_Rep 
OR  Partial_Rev_SOR_Loop_Perimeter_Rep 
OR  Full_Rev_SOR_Vertex_Perimeter_Rep 
OR  Surface_Perimeter_Rep 
OR  Unstruct_Geometry_Perimeter_Rep 
OR  Wireframe_Perimeter_Rep  ); 

END_ENTITY; 


N2 


PageD3.1.1-116 


ISO  TC184/SC4/WG1 


ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


N2  8 8 


Section  1:  INTEGRATION  CORE  MODEL 
Entity  Name:  Perimeter  Shape  Element 

Entity  Number:  INT-18 


Entity  Definition:  A "Dimensionality  1 Shape  Element"  that  is  a dosed  boundary 
of  a "Maximal  Area  Shape  Element". 

Business  Rules:  Eyery  "Perimeter  Shape  Element": 

• is  a "Dimensionality  1 Shape  Element". 

• is  represented  by  zero,  one,  or  more  "Perimeter 
Representations". 

Primary  Key  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Other  Attributes:  none 

SML: 


ENTITY  Perimeter-Shape-Element 

CATEGORY  BY  Dim-l-SE-Type  OF  E>imensionality-l-Shap>e-Element 
ENDE 

EXPRESS: 


ENTITY  Perimeter_Shape_Element 

SUBTYPE  OF  ( Dimensionality_l_Shape_Element  ); 
Representations  : LIST  OF  [ 0 : # ] OF  Perimeter_Representation; 
END.ENTITY; 
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Entity  Name: 
Entity  Number: 

Entity  Definition: 

Business  Rules: 


Section  1:  INTEGRATION  CORE  MODEL 


Point 

GEO-2 

Defined  in  the  PDES  Geometry  reference  model. 

Every  "Point"  is  used  as  zero,  one,  or  more  "Facetted  Brep  Dim  0 
SE  Reps". 
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Entity  Name: 
Entity  Number: 

Entity  Definition: 

Business  Rules: 


Section  1:  INTEGRATION  CORE  MODEL 
Polyloop 
TOP-11 

Defined  in  the  PDES  Topology  reference  model. 

Eyery  Tolyloop"  is  used  as  zero,  one,  or  more  "Facetted  Br^p 
Perimeter  Reps". 
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Entity  Name: 
Entity  Number: 

Entity  Definition: 

Business  Rules: 


Section  1:  INTEGRATION  CORE  MODEL 

Product  Item 
PSCM-1 

Defined  in  the  PDES  PSCM  reference  model. 

Every  "Product  Item"  has  one  or  more  "Product  Item  Versions". 
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Entity  Name: 
Entity  Number: 

Entity  Definition: 

Business  Rules: 


Section  1:  INTEGRATION  CORE  MODEL 
Product  Item  Version 
PSCM.2 

Defined  in  the  PDES  PSCM  reference  model. 

Eyery  "Product  Item  Version": 

• is  for  one,  and  only  one,  "Product  Item". 

• is  described  by  one  or  more  "Product  Item  Version 
Functional  Definitions". 
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Entity  Name: 
Entity  Number: 

Entity  Definition: 

Business  Rules: 


Section  1:  INTEGRATION  CORE  MODEL 


Product  Item  Version  Definition  Shape 
PSCM-27 

Defined  in  the  PDES  PSCM  reference  model. 

Every  'Troduct  Item  Version  Definition  Shape": 

• is  the  primary  shape  for  one,  and  only  one,  "Product  Item 
Version  Functional  Definition". 

• is  one,  and  only  one,  "Shape". 
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Entity  Name: 
Entity  Number: 

Entity  Definition 

Business  Rules: 


Section  1:  INTEGRATION  CORE  MODEL 

Product  Item  Version  Functional  Definition 

PSCM-4 

Defined  in  the  PDES  PSCM  reference  model. 

Every  "Product  Item  Version  Functional  Definition": 

• describes  one,  and  only  one,  "Product  Item  Version". 

• has  a primary  shape  of  zero  or  one  "Product  Item  Version 
Definition  Shape". 

• is  modeled  by  zero,  one,  or  more  "FEM  Product  Item 
Version  Definitions". 
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Stction  1:  INTEGRATION  CORE  MODEL 
Entity  Name:  Seam  Representation 

Entity  Number:  INT-63 


Entity  Definition:  The  symbolic  description  of  a "Seam  Shape  Element"  in  a 

"Geometric  Model". 


Business  Rules:  Eyery  "Seam  Representation": 

• represents  one,  and  only  one,  "Seam  Shape  Element". 

• must  be  one,  and  only  one,  of  the  following: 

"Brep  Seam  Rep" 

"SOLE  Edge  Seam  Rep" 

"SOLE  Vertex  Seam  Rep" 

"Partial  Rey  SOR  Edge  Seam  Rep" 

"SOR  Vertex  Seam  Rep" 

"Surface  Seam  Rep" 

"Unstruct  Geometry  Seam  Rep" 

"Wireframe  Seam  Rep" 

Primary  Key  Attributes: 


Shape  ID 
Shape  Elem  ID 
Seam  Rep  ID 


Other  Attributes: 


Seam  Rep  Type 


(FK) 

(FK) 

The  means  of  distinguishing  each  "Seam 
Representation"  from  all  the  others  for  the  same 
"Seam  Shape  Element". 


The  means  of  determining  whether  a "Seam 
Representation"  is  a(n): 

"Brep  Seam  Rep", 

"SOLE  Edge  Seam  Rep", 

"SOLE  Vertex  Seam  Rep", 

"Partial  Rey  SOR  Edge  Seam  Rep", 

"SOR  Vertex  Seam  Rep", 

"Surface  Seam  Rep", 

"Unstruct  Geometry  Seam  Rep",  or 
"Wireframe  Seam  Rep". 
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Section  1:  INTEGRATION  CORE  MODEL 

SML: 

ENTITY  Seam-Representation 
KEY 

Seam-Shape-Element  "U  represented  by" 
Seam-Rep-ID 
ENDK 

Seam-Rep-Type  NONULL 
ENDE 

EXPRESS: 


ENTITY  Seam_Representation 

SUPERTYPE  OF  ( Brep_Seam_Rep 

OR  SOLE_Edge_Seam_Rep 
OR  SOLE_Vertex_Sean^_Rep 
OR  Partial_Rev_SOR_Edge_Seani_Rep 
OR  SOR_Vertex_Seam_Rep 
OR  Surface_Seam_Rep 
OR  Unstruct_Geometry_Seam_Rep 
OR  Wireframe_Seam_Rep  ); 


END.ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 
Entity  Name:  Seam  Shape  Element 

Entity  Number:  INT-14 


Entity  Definition:  A "Dimensionality  1 Shape  Element"  that  has  a uniform 
imderlying  mathematical  curve. 

Business  Rules:  Every  "Seam  Shape  Element": 

• is  a "Dimensionality  1 Shape  Element". 

• must  be  one,  and  only  one,  of  the  following: 

"Edge  Shape  Element" 

"Interior  ^am  Shape  Element" 

"Subedge  Shape  Element" 

• is  represented  by  zero,  one,  or  more  "Seam 
Representations". 

Primary  Kev  Attributes: 


Shape  ID 
Shape  Elem  ID 

Other  Attributes: 


Seam  SE  Type 


(FK) 

(FK) 


The  means  of  determining  whether  a "Seam  Shape 
Element"  is  a(n): 

"Edge  Shape  Element", 

"Interior  Seam  Shape  Element",  or 
"Subedge  Shape  Element". 


SML: 


ENTITY  Seam-Shape-Element 

CATEGORY  BY  Dim-l-SE-Type  OF  Dimensionality-l-Shape-Element 
Seam-SE-Type  NONULL 
ENDE 

EXPRESS: 


ENTITY  Seam_Shape_Element 

SUPERTYPE  OF  ( Edge_Shape_Element 

OR  Subedge_Shape-Element 
OR  Interior_Seam_Shape-Element  ) 
SUBTYPE  OF  ( Dimensionality_l_Shape_Element  ); 
Representations  : LIST  OF  [ 0 : # ] OF  Seam_Representation; 
END.ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name:  Shape 

Entity  Number:  INT-1 


Entity  Definition:  The  size,  spatial  configuration,  and  proportions  of  a real  or 
conceiyed  thing,  independent  of  whether  or  how  it  is 
represented. 

Business  Rules:  Eyery  "Shape": 

• is  an  aggregation  zero,  one,  or  more  "Shape  Elements". 

• is  the  primary  shape  for  zero,  one,  more  "Product  Item 
Version  Definition  Shapes". 


Primary  Key  Attributes: 

Shape  ID  The  means  of  distinguishing  each  "Shape"  from  all 

others. 

Other  Attributes:  none 

SML: 


ENTITY  Shape 
KEY 

Shape-ID 

ENDK 

ENDE 

EXPRESS: 

ENTITY  Shape; 

Elements  : LIST  OF  [ 0 : # ] Shape_EIement; 
END_ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name: 
Entity  Number: 


Shape  Element 
INT-2 


Entity  Definition:  A distinguishable  aspect  of  a "Shape". 


Business  Rules: 


Eyery  "Shape  Element": 

• is  part  of  one,  and  only  one,  "Shape". 

• must  be  one,  and  only  one,  of  the  following: 

"Dimensionality  0 Shape  Element" 
"Dimensionality  1 Shape  Element" 
"Dimensionality  2 Shape  Element" 
"Dimensionality  3 Shape  Element" 


Primary  Key  Attributes: 


(FK) 

The  means  of  distinguishing  each  "Shape  Element" 
from  all  the  others  belonging  to  the  same  "Shape". 


The  means  of  determining  whether  a "Shape 
Element"  is  a(n): 

"Dimensionality  0 Shape  Element", 
"Dimensionality  1 Shape  Element", 
"Dimensionality  2 Shape  Element",  or 
"Dimensionality  3 Shape  Element". 

SML: 

ENTITY  Shape-Element 
KEY 

Shape  "is  aggregation  of’ 

Shape-Elem-ID 

ENDK 

Shape-Elem-Type  NONULL 
ENDE 


Shape  ID 

Shape  Element  ID 

Other  Attributes: 

Shape  Element  Type 
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Section  1:  INTEGRATION  CORE  MODEL 


EXPRESS: 


ENTITY  Shape_Element 
SUPERTYPE  OF  ( 
OR 
OR 
OR 


END.ENTITY; 


Dimensionality_0_Shape_Element 
Dimensionality_l_Shape_Element 
Dimensionality_2_Shape_Element 
Dimensionality_3_Shape_Element  ); 
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Section  1:  INTEGRATION  CORE  MODEL 

Entitv  Name: 

Shell 

Entity  Number: 

TOP-6 

Entitv  Definition: 

Defined  in  the  PDES  Topology  reference  model. 

Business  Rules: 

Every  "Shell": 

• is  used  as  zero,  one,  or  more  "Brep  Volume  Reps". 

• is  used  as  zero,  one,  or  more  "Facetted  Brep  Volume 
Reps". 
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Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name:  SOLE  Dim  0 SE  Rep 

Entity  Number:  CnJT-SS 


Entity  Definition:  The  use  of  a "Vertex"  in  a "Solid  of  Linear  Extrusion  Model"  to 
represent  a "Dimensionality  0 Shape  Element". 

Business  Rules:  Every  "SOLE  Dim  0 SE  Rep": 

• is  a "Dim  0 Shape  Element  Representation". 

• is  in  one,  and  only  one,  "Solid  of  Linear  Extrusion 
Model". 

• is  one,  and  only  one,  "Vertex". 


Primary  Key  Attributes: 

Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Dim  0 Rep  ID  (FK) 

Other  Attributes: 


SOLE  Model  ID 
Vertex  ID 

Dim  0 Start  or  End  Face 


(FK) 

(FK) 

Indicates  whether  the  "SOLE  Dim  0 SE  Rep"  is  on 
the  starting  or  ending  face  in  the  "Solid  of  Linear 
Extrusion  Model". 


SML: 


ENTITY  SOLE-Dim-O-SE-Rep 

CATEGORY  BY  Dim-O-Rep-Type  OF  Dim-O-Shape-Element-Representation 
Vertex  "is  used  as"  NONULL 

Solid-of-Linear-Exh-usion-Model  "is  context  of  NONULL 
Dim-O-Start-or-End-Face  NONULL 
ENDE 
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EXPRESS: 

TYPE 

SOLE_Face_Typ€S  = 

ENUMERATION  OF  ( Starting_SOLE_Face,  Ending_SOLE_Face  ); 
END_TYPE; 

ENTITY  SOLE_Dim_0_SE_Rep 

SUBTYPE  OF  ( Dim_0_Shape_Element_Representation  ); 
Definition  : Vertex; 

Context  : Solid_of_Linear_Extrusion_Model; 

Face  : SOLE_Face_Types; 

END_ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name:  SOLE  Edge  Area  Rep 

Entity  Number:  INT-50 


Entity  Definition:  The  use  of  an  "Edge"  in  a "Solid  of  Linear  Extrusion  Model"  to 
represent  an  "Area  Shape  Element",  An  edge  of  the  swept  face 
sweeps  a surface  area  of  the  prismatic  solid.  If  the  edge  has  an 
adjacent  edge  with  the  same  underlying  curve,  the  area  is 
nonmaximal;  otherwise,  the  area  is  maximal. 


Business  Rules:  Every  "SOLE  Edge  Area  Rep": 

• is  an  "Area  Representation". 

• is  in  one,  and  only  one,  "Solid  of  Linear  Extrusion 
Model". 

• is  one,  and  only  one,  "Edge". 

Primary  Key  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Area  Rep  ID  (FK) 

Other  Attributes: 

SOLE  Model  ID  (FK) 

Edge  ID  (FK) 


SML: 

ENTITY  SOLE-Edge-Area-Rep 

CATEGORY  BY  Area-Rep-Type  OF  Area-Representation 
Edge  "is  used  as"  NONULL 

Solid-of-Linear-Extrusion-Model  "is  context  of  NONULL 
ENDE 

EXPRESS: 


ENTITY  SOLE_Edge_Area_Rep 

SUBTYPE  OF  ( Area_Representation  ); 
Definition  : Edge; 

Context  : Solid_of_Linear_Extrusion_Model; 
END_ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 
Entity  Name:  SOLE  Edge  NM  Area  Rep 

Entity  Number:  INT-60 


Entity  Definition:  The  use  of  an  "Edge"  in  a "Solid  of  Linear  Extrusion  Model"  to 
represent  a "Nonmaximal  Area  Shape  Element".  An  edge  of  a 
subface  of  the  face  swept  by  an  SOLE  sweeps  a portion  of  the 
surface  area  of  the  solid,  provided  that  the  edge  is  a portion  of  an 
edge  of  the  swept  face.  If,  in  addition,  the  subface  edge  is  a proper 
subset  of  the  swept  face  edge,  the  edge  sweeps  a nonmaximal 
area.  (If  the  subface  edge  is  an  entire  edge  of  the  swept  face,  it 
seems  pxjintless  to  regard  the  subface  edge  as  the  representation 
of  the  swept  area;  the  swept  face  edge  is  available  and  more 
natural.  TTierefore,  it  is  considered  that  only  a nonmaximal  area 
can  be  represented  by  an  edge  of  a subface  of  the  swept  face.) 


Business  Rules:  Every  "SOLE  Edge  NM  Area  Rep": 

• is  a "Nonmaximal  Area  Representation". 

• is  in  one,  and  only  one,  "Solid  of  Linear  Extrusion 
Model". 

• is  one,  and  only  one,  "Edge". 


Primary  Key  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Nonmax  Area  Rep  ID  (FK) 

Other  Attributes: 

SOLE  Model  ID  (FK) 

Edge  ID  (FK) 


SML: 


ENTITY  SOLE-Edge-NM-Area-Rep 

CATEGORY  BY  Nonmax-Area-Rep-Type 
OF  Nonmaximal- Area-Representation 
Edge  "is  used  as"  NONULL 

Solid-of-Linear-Extrusion-Model  "is  context  of  NONULL 
ENDE 
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EXPRESS: 

ENTITY  SOLE_Edge_NM_Area_Rep 

SUBTYPE  OF  ( Nonmaximal_Area_Representation  ); 
Definition  : Edge; 

Context  : Solid_of_Linear_ExtTusion_Model; 

END.ENTITY; 


Page  D3.1.M35 


ISO  TC184/SC4/WG1 


ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


N288 


Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name:  SOLE  Edge  Perimeter  Rep 

Entity  Number:  INT-82 


Entity  Definition:  The  use  of  an  "Edge"  in  a "Solid  of  Linear  Extrusion  Model"  to 
represent  a Terimeter  Shape  Element". 

Business  Rules:  Every  "SOLE  Edge  Perimeter  Rep": 

• is  a "Perimeter  Representation". 

• is  in  one,  and  only  one,  "Solid  of  Linear  Extrusion 
Model". 

• is  one,  and  only  one,  "Edge". 

Primary  Kev  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Perim  Rep  ID  (FK) 

Other  Attributes: 

SOLE  Model  ID  (FK) 

Edge  ID  (FK) 


SML: 

ENTITY  SOLE-Edge-Perimeter-Rep 

CATEGORY  BY  Perim-Rep-Type  OF  Perimeter-Representation 
Edge  "is  used  as"  NONULL 

Solid-of-Linear-Extrusion-Model  "is  context  of  NONULL 
ENDE 


EXPRESS: 


ENTITY  SOLE_Edge_Perimeter_Rep 

SUBTYPE  OF  ( Perimeter_Representation  ); 
Definition  : Edge; 

Context  : Solid_of_Linear_Extrusion_Model; 
END.ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name:  SOLE  Edge  Seam  Rep 

Entity  Number:  INT-68 


Entity  Definition:  The  use  of  an  "Edge”  in  a "Solid  of  Linear  Extrusion  Model"  to 
represent  a "Seam  Shape  Element".  An  edge  of  the  face  swept  by 
an  SOLE  corresponds  to  some  or  all  of  a seam  between  the  "base" 
or  "cap"  of  the  prismatic  solid  and  a side  area  of  the  solid.  If  the 
edge  has  no  adjacent  face  with  the  same  underlying  curye,  the 
seam  is  an  "Edge  Shape  Element",  i.e.,  the  intersection  of 
maximal  areas.  If  there  is  an  adjacent  face  with  the  same 
underlying  curve,  the  seam  is  a "Subedge  Shape  Element".  An 
"Interior  ^am  Shape  Element"  cannot  be  represented  in  this 
way. 


Business  Rules:  Every  "SOLE  Edge  Seam  Rep": 

• is  a "Seam  Representation". 

• is  in  one,  and  only  one,  "Solid  of  Linear  Extrusion 
Model". 

• is  one,  and  only  one,  "Edge". 


Primary  Kev  Attributes: 


Shape  ID 

(FK) 

Shape  Elem  ID 

(FK) 

Seam  Rep  ID 

(FK) 

Other  Attributes: 

SOLE  Model  ID 

(FK) 

Edge  ID 

SOLE  Seam  Start  or 

(FK) 

End  Face  Indicates  whether  the  "SOLE  Edge  Seam  Rep"  is  on 

the  starting  or  ending  face  in  the  "Solid  of  Linear 
Extrusion  Model". 

SML: 


ENTITY  SOLE-Edge-Seam-Rep 

CATEGORY  BY  Seam-Rep-Type  OF  Seam-Representation 
Edge  "is  used  as"  NONULL 

Solid-of-Linear-Extrusion-Model  "is  context  of"  NONULL 
SOLE-Seam-Start-or-End-Face  NONULL 
ENDE 
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ENTITY  SOLE_Edge_Seam_Rep 

SUBTYPE  OF  ( S€am_Representation  ); 
Definition  : Edge; 

Context  : Solid_of_Linear_Extrusion_Model; 
Face  ; SOLE_Face_Types; 

END_ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name:  SOLE  Loop  Perimeter  Rep 

Entity  Number:  INT-78 


Entity  Definition:  The  use  of  a "Loop"  in  a "Solid  of  Linear  Extrusion  Model"  to 
represent  a "Perimeter  Shape  Element". 

Business  Rules:  Eyery  "SOLE  Loop  Perimeter  Rep": 

• is  a "Perimeter  Representation". 

• is  in  one,  and  only  one,  "Solid  of  Linear  Extrusion 
Model". 

• is  one,  and  only  one,  "Loop". 


Primary  Key  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Perim  Rep  ID  (FK) 

Other  Attributes: 

SOLE  Model  ID  (FK) 

Loop  ID  (FK) 


SOLE  Perim  Start  or 


End  Face  Indicates  whether  the  "SOLE  Loop  Perimeter  Rep" 

is  on  the  starting  or  ending  face  in  the  "Solid  of 
Linear  Extrusion  Model". 


SML: 


ENTITY  SOLE-Loop-Perimeter-Rep 

CATEGORY  BY  Perim-Rep-Type  OF  Perimeter-Representation 
Loop  "is  used  as"  NONULL 

Solid-of-Linear-Extrusion-Model  "is  context  of  NONULL 
SOLE-Perim-Start-or-End-Face  NONULL 
ENDE 

EXPRESS: 

ENTITY  SOLE_Loop_Perimeter_Rep 

SUBTYPE  OF  ( Perimeter_Representation  ); 

Definition  : Loop; 

Context  : Solid_of_Linear_ExtTusion_Model; 

Face  : SOLE_Face_Types; 

END_ENTITY; 


Page  D3.1.M39 


■ 


ISO  TC184/SC4/WG1 


Entity  Name: 


ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


Section  1:  INTEGRATION  CORE  MODEL 


SOLE  Max  Area  Rep 


Entity  Number:  INT-47 


N288 


Entity  Definition:  The  use  of  a "Solid  of  Linear  Extrusion  Model"  to  represent  an 

"Maximal  Area  Shape  Element".  The  swept  face  of  an  SOLE 
corresponds  to  two  surface  areas  of  the  solid;  the  "base"  and  the 
"cap"  of  the  prism.  By  the  nature  of  an  SOLE,  these  two  areas  are 
necessarily  maximal. 


Business  Rules:  Every  "SOLE  Max  Area  Rep": 

• is  a "Maximal  Area  Representation". 

• is  one,  and  only  one,  "^lid  of  Linear  Extrusion  Model". 

Primary  Key  Attributes: 


Shape  ID 

(FK) 

Shape  Elem  ID 

(FK) 

Area  Rep  ID 

(FK) 

Other  Attributes: 

SOLE  Model  ID 
SOLE  Max  Area  Start  or 
End  Face 


(FK) 

Indicates  whether  the  "SOLE  Max  Area  Rep"  is  on 
the  starting  or  ending  face  in  the  "Solid  of  Linear 
Extrusion  Model". 


SML: 

ENTITY  SOLE-Max-Area-Rep 

CATEGORY  BY  Max-Area-Rep-Type  OF  Maximal-Area-Representation 
Solid-of-Linear-Extrusion-Model  "is  used  as"  NONULL 
SOLE-Max-Area-Start-or-End-Face  NONULL 
ENDE 

EXPRESS: 


ENTITY  SOLE_Max_Area_Rep 

SUBTYPE  OF  ( Maximal_Area_Representation  ); 
Definition  : Solid_of_Linear_Extrusion_Model; 

Face  : SOLE_Face_Types; 

END_ENTITY; 
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Entity  Name: 


Section  1:  INTEGRATION  CORE  MODEL 

SOLE  Subface  NM  Area  Rep 


Entity  Number:  INT-57 

Entity  Definition:  The  use  of  a "Subface"  in  a "Solid  of  Linear  Extrusion  Model"  to 
represent  a "Nonmaximal  Area  Shape  Element".  A subface  of 
the  face  swept  of  an  SOLE  corresponds  to  two  surface  areas  of  the 
solid.  These  are  nonmaximal  areas:  one  being  a subset  of  the 
"base"  of  the  prismatic  solid;  the  other,  a subset  of  the  "cap". 


Business  Rules: 


Every  "SOLE  Subface  NM  Area  Rep": 

• is  a "Nonmaximal  Area  Representation". 

• is  in  one,  and  only  one,  "Solid  of  Linear  Extrusion 
Model". 

• is  one,  and  only  one,  "Subface". 


Primary  Key  Attributes: 

Shape  ID  (FK) 

Sha]:>e  Elem  ID  (FK) 

Nonmax  Area  Rep  ID  (FK) 

Other  Attributes: 


SOLE  Model  ID 
Subface  ID 

SOLE  Nonmax  Area  Start 
or  End  Face 


(FK) 

(FK) 

Indicates  whether  the  "SOLE  Subface  NM  Area 
Rep"  is  on  the  starting  or  ending  face  in  the  "Solid 
of  Linear  Extrusion  Model". 


SML: 


ENTITY  SOLE-SubfaceNM-Area-Rep 

CATEGORY  BY  Nonmax-Area-Rep-Type 
OF  Nonmaximal- Area-Representation 
Subface  "is  used  as"  NONULL 

Solid-of-Linear-Extrusion-Model  "is  context  of  NONULL 
SOLE-Nonmax-Area-Start-or-End-Face  NONULL 
ENDE 
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EXPRESS: 


ENTITY  SOLE_Subface_NM_Area_Rep 

SUBTYPE  OF  ( Nonmaximal_Area_Representation  ); 
Definition  : Subface; 

Context  : Solid_of_Linear_Extrusion_Model; 

Face  ; SOLE_Face_Types; 

END_ENTITY;~ 


N288 
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Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name:  SOLE  Vertex  Seam  Rep 


Entity  Number:  INT-71 

Entity  Definition:  The  use  of  a "Vertex"  in  a "Solid  of  Linear  Extnision  Model"  to 
represent  a "Seam  Shape  Element". 


Business  Rules:  Eyery  "SOLE  Vertex  Seam  Rep": 

• is  a "Seam  Representation". 

• is  in  one,  and  only  one,  "Solid  of  Linear  Extrusion 
Model". 

• is  one,  and  only  one,  "Vertex". 

Primary  Key  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Seam  Rep  ID  (FK) 

Other  Attributes: 

SOLE  Model  ID  (FK) 

Vertex  ID  (FK) 


SML: 

ENTITY  SOLE-Vertex-Seam-Rep 

CATEGORY  BY  Seam-Rep>-Type  OF  Seam-Representation 
Vertex  "is  used  as"  NONULL 

Solid-of-Linear-Extrusion-Model  "is  context  of  NONULL 
ENDE 

EXPRESS: 

ENTITY  SOLE_Vertex_Seam_Rep 

SUBTYPE  OF  ( Seam_Representation  ); 

Definition  : Vertex; 

Context  : Solid_of_Linear_Extrusion_Model; 
END.ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name:  SOLE  Volume  Rep 

Entity  Number:  INT-40 


Entity  Definition:  The  use  of  a "Solid  of  Linear  Extrusion  Model"  to  represent  a 
"Voidless  Volume  Shape  Element".  An  SOLE  is  a solid  model 
Since  an  SOLE  is  a sweep  of  a single  face,  the  solid  must  have  a 
connected  interior.  The  nature  of  the  representation  makes  it 
impossible  for  the  solid  to  have  any  voids. 


Business  Rules:  Every  "SOLE  Volume  Rep": 

• is  a "Voidless  Volume  Representation". 

• is  one,  and  only  one,  "Solid  of  Linear  Extrusion  Model". 

Primary  Key  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Volume  Rep  ID  (FK) 

Other  Attributes: 

SOLE  Model  ID  (FK) 


SML: 


ENTITY  SOLE- Volume-Rep 

CATEGORY  BY  Volume-Rep-Type  OF  Voidless-Volume-Representation 
Solid-of-Linear-Extrusion-Model  "is  used  as"  NONULL 
ENDE 

EXPRESS: 


ENTITY  SOLE_Volume_Rep 

SUBTYPE  OF  ( Voidless_Volume_Representation  ); 
Definition  : Solid_of„Linear_Extrusion_Model; 
END.ENTITY; 
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Entity  Name: 
Entity  Number: 

Entity  Definition: 

Business  Rules: 


Section  1:  INTEGRATION  CORE  MODEL 

Solid  of  Linear  Extrusion  Model 

GEO106 

Defined  in  the  PDES  Geometry  reference  model. 

Every  "Solid  of  Linear  Extrusion  Model": 

• is  a "Geometric  Model". 

• is  the  context  of  zero,  one,  or  more  "SOLE  Dim  0 SE  Reps". 

• is  the  context  of  zero,  one,  or  more  "SOLE  Edge  Area 
Reps". 

• is  ^e  context  of  zero,  one,  or  more  "SOLE  Edge  NM  Area 
Reps". 

• is  the  context  of  zero,  one,  or  more  "SOLE  Edge  Perimeter 
Reps". 

• is  the  context  of  zero,  one,  or  more  "SOLE  Edge  Seam 
Reps". 

• is  used  as  zero,  one,  or  more  "SOLE  Max  Area  Reps". 

• is  the  context  of  zero,  one,  or  more  "SOLE  Loop  Perimeter 
Reps". 

• is  the  context  of  zero,  one,  or  more  "SOLE  Subface  NM 
Area  Reps". 

• is  the  context  of  zero,  one,  or  more  "SOLE  Vertex  Seam 
Reps". 

• is  used  as  zero,  one,  or  more  "SOLE  Volume  Reps". 


Page  D3.1.M45 


ISO  TC184/SC4/WG1 


ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


N2  8 8 


Entity  Name: 
Entity  Number: 

Entity  Definition 

Business  Rules: 


Section  1:  INTEGRATION  CORE  MODEL 

Solid  of  Reyolution  Model 

GEO107 

IDefined  in  the  PDES  Geometry  reference  model. 

Eyery  "Solid  of  Revolution  Model": 

• is  a "Geometric  Model". 

• revolves  one,  and  only  one,  "Face". 

• is  the  context  of  zero,  one,  or  more  "Full  Rev  SOR  Corner 
Reps". 

• is  the  context  of  zero,  one,  or  more  "Full  Rev  SOR  Int  Loc 
Reps". 

• is  used  as  zero,  one,  or  more  "Full  Rev  SOR  Object  Reps". 

• is  the  context  of  zero,  one,  or  more  "Full  Rev  SOR 
Volume  Reps". 

• is  the  context  of  zero,  one,  or  more  "Partial  Rev  SOR  Bdry 
Lx)c  Reps". 

• is  the  context  of  zero,  one,  or  more  "Partial  Rev  SOR 
Comer  Reps". 

• is  the  context  of  zero,  one,  or  more  "Partial  Rev  SOR  Int 
Loc  Reps". 

• is  used  as  zero,  one,  or  more  'Partial  Rev  SOR  Volume 
Reps". 

• is  the  context  of  zero,  one,  or  more  "SOR  Edge  Area  Reps". 

• is  the  context  of  zero,  one,  or  more  "SOR  Edge  NM  Area 
Reps". 

• is  the  context  of  zero,  one,  or  more  Tartial  Rev  SOR  Edge 
Perimeter  Reps". 

• is  the  context  of  zero,  one,  or  more  'Partial  Rev  SOR  Edge 
Seam  Reps". 

• is  used  as  zero,  one,  or  more  "Partial  Rev  SOR  Max  Area 
Reps". 

• is  the  context  of  zero,  one,  or  more  "Partial  Rev  SOR  Loop 
Perimeter  Reps". 

• is  the  context  of  zero,  one,  or  more  "Partial  Rev  SOR 
Subface  NM  Area  Reps". 

• is  the  context  of  zero,  one,  or  more  "Full  Rev  SOR  Vertex 
Perimeter  Reps". 

• is  the  context  of  zero,  one,  or  more  "SOR  Vertex  Seam 
Reps". 
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Entity  Name: 
Entity  Number: 

Entity  Definition: 


SOR  Edge  Area  Rep 
INT-49 

The  use  of  an  "Edge"  in  a "Solid  of  Revolution  Model"  to 
represent  an  "Area  Shape  Element". 


Business  Rules:  Every  "SOR  Edge  Area  Rep": 

• is  an  "Area  Representation". 

• is  in  one,  and  only  one,  "Solid  of  Revolution  Model". 

• is  one,  and  only  one,  "Edge". 

Primary  Key  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Area  Rep  ID  (FK) 

Other  Attributes: 

SOR  Model  ID  (FK) 

Edge  ID  (FK) 


SML: 


ENTITY  SOR-Edge- Area-Rep 

CATEGORY  BY  Area-Rep-Type  OF  Area-Representation 
Edge  "is  used  as"  NONULL 

Solid-of-Revolution-Model  "is  context  of"  NONULL 
ENDE 

EXPRESS: 


ENTITY  SOR_Edge_Area_Rep 

SUBTYPE  OF  ( Area_Representation  ); 
Definition  : Edge; 

Context  : Solid_of_Revolution_Model; 
END_ENTITY; 
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Entity  Name:  SOR  Edge  NM  Area  Rep 

Entity  Number:  INT-59 


Entity  Definition:  The  use  of  an  "Edge"  in  a "Solid  of  Revolution  Model"  to 
represent  a "Nonmaximal  Area  Shape  Element". 

Business  Rules:  Every  "SOR  Edge  NM  Area  Rep": 

• is  a "Nonmaximal  Area  Representation". 

• is  in  one,  and  only  one,  "Solid  of  Revolution  Model". 

• is  one,  and  only  one,  "Edge". 


Primary  Key  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Nonmax  Area  Rep  ID  (FK) 

Other  Attributes: 

SOR  Model  ID  (FK) 

Edge  ID  (FK) 


SML: 


ENTITY  SOR-Edge-NM-Area-Rep 

CATEGORY  BY  Nonmax-Area-Rep-Type 
OF  Nonmaximal-Area-Representation 
Edge  "is  used  as"  NONULL 

Solid-of-Revolution-Model  "is  context  of"  NONULL 
ENDE 

EXPRESS: 


ENTITY  SOR_Edge_NM_Area_Rep 

SUBTYPE  OF  ( Nonmaximal_Area_Representation  ); 
Definition  : Edge; 

Context  : Solid_of_Revolution_Model; 

END.ENTITY; 
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ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


N288 


Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name: 
Entity  Number: 

Entity  Definition: 


SOR  Vertex  Seam  Rep 
INT-70 

The  use  of  a "Vertex”  in  a "Solid  of  Reyolution  Model"  to 
represent  a "Seam  Shape  Element". 


Business  Rules:  Eyery  "SOR  Vertex  Seam  Rep": 

• is  a "Seam  Representation". 

• is  in  one,  and  only  one,  "Solid  of  Reyolution  Model". 

• is  one,  and  only  one,  "Vertex". 

Primary  Key  Attributes: 

Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Seam  Rep  ID  (FK) 


Other  Attributes: 


SOR  Model  ID  (FK) 

Vertex  ID  (FK) 


SML: 


ENTITY  SOR-Vertex-Seam-Rep 

CATEGORY  BY  Seam-Rep-Type  OF  Seam-Representation 
Vertex  "is  used  as"  NONULL 

Solid-of-Reyolution-Model  "is  context  of"  NONULL 
ENDE 

EXPRESS: 


ENTITY  SOR_Vertex_Seam_Rep 

SUBTYPE  OF  ( Seam_Representation  ); 
Definition  : Vertex; 

Context  : Solid_of_Reyolution_Model; 
END_ENTITY; 


Page  D3.1. 1-149 


rroposaij 


Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name:  Subedge  Shape  Element 

Entity  Number:  INT-16 

Entity  Definition:  A "Seam  Shape  Element"  that  is  a proper  subset  of  an  "Edge 

Shape  Element". 

Business  Rules:  Every  "Subedge  Shape  Element"  is  a "Seam  Shape  Element". 
Primary  Key  Attributes: 


Shape  ID 
Shape  Elem  ID 

Other  Attributes: 


(FK) 

(FK) 

none 


SML: 


ENTITY  Subedge-Shape-Element 

CATEGORY  BY  Seam-SE-Type  OF  Seam-Shape-Element 
ENDE 

EXPRESS: 


ENTITY  Subedge_Shape_Element 

SUBTYPE  OF  ( Seam_Shape_Element  ); 
END_ENTITY; 


PageD3.1.1-150 


ISO  TC184/SC4/WG1 


Entity  Name: 
Entity  Number: 

Entity  Dermition: 

Business  Rules: 


ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


Section  1:  INTEGRATION  CORE  MODEL 


N288 


Subface 

TOP-8 

Defined  in  the  PDES  Topology  reference  model. 


Eyery  "Subface”: 

• is  used  as  zero,  one,  or  more  "Brep  NM  Area  Reps". 

• is  used  as  zero,  one,  or  more  "Facetted  Brep  NM  Area 
Reps". 

• is  used  as  zero,  one,  or  more  "SOLE  Subface  NM  Area 
Reps". 

• is  used  as  zero,  one,  or  more  "Partial  Rey  SOR  Subface 
NM  Area  Reps". 

• is  used  as  zero,  one,  or  more  "Surface  NM  Area  Reps". 
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Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name:  Surface  Area  Rep 

Entity  Number:  INT-45 

Entity  Definition:  The  use  of  a "Face"  in  a "Surface  Model"  to  represent  an  "Area 
Shape  Element".  In  a surface  model,  a face  is  typically  employed 
to  represent  a portion  of  surface  area  that  (i)  has  a uniform 
underlying  surface  and  (ii)  is  arcwise  connected.  If  there  is  an 
adjacent  face  with  the  same  underlying  surface,  the  area  is  not 
maximal;  otherwise,  it  is  maximal. 


Business  Rules:  Every  "Surface  Area  Rep": 

• is  an  "Area  Representation". 

• is  in  one,  and  only  one,  "Surface  Model". 

• is  one,  and  only  one,  "Face". 


Primary  Kev  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Area  Rep  ID  (FK) 

Other  Attributes: 

Surface  Model  ID  (FK) 

Face  ID  (FK) 


SML: 


i 


ENTITY  Surface-Area-Rep 

CATEGORY  BY  Area-Rep-Type  OF  Area-Representation 
Face  "is  used  as"  NONULL 
Surface-Model  "is  context  of  NONULL 
ENDE 

EXPRESS: 

ENTITY  Surface_Area_Rep 

SUBTYPE  OF  ( Area_Representation  ); 
Definition  : Face; 

Context  : Surface_Model; 

END.ENTITY; 
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N2S8 


Entity  Name:  Surface  Dim  0 SE  Rep 

Entity  Number:  INT-86 


Entity  Definition:  The  use  of  a "Vertex"  in  a "Surface  Model"  to  represent  a 

"Dimensionality  0 Shape  Element".  In  a surface  model,  yertices 
are  employed  in  maximal  faces,  nonmaximal  faces,  subfaces,  and 
yertex  loops.  In  the  first  three  cases,  the  edges  that  meet  at  the 
vertex  may  have  the  same  underlying  curve.  So,  a vertex  may 
represent  any  of  the  three  categories  of  "Dimensionality  0 Shape 
Element"  — comer,  boundary  location,  or  interior  location. 


Business  Rules:  Every  "Surface  Dim  0 SE  Rep"; 

• is  a "Dim  0 Shape  Element  Representation". 

• is  in  one,  and  only  one,  "Surface  Model". 

• is  one,  and  only  one,  "Vertex". 


Primary  Key  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Dim  0 Rep  ID  (FK) 

Other  Attributes: 

Surface  Model  ID  (FK) 

Vertex  ID  (FK) 


SML: 


ENTITY  Surface-Dim-O-SE-Rep 

CATEGORY  BY  Dim-O-Rep-Type  OF  Dim-O-Shape-Element-Representation 
Vertex  "is  used  as"  NONULL 
Surface-Model  "is  used  as"  NONULL 
ENDE 

EXPRESS: 


ENTITY  Surface_Dim_0_SE_Rep 

SUBTYPE  OF  ( Dim_0_Shape_Element_Representation  ); 
Definition  : Vertex; 

Context  : Surface_Model; 

END.ENTITY; 
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Stction  1:  INTEGRATION  CORE  MODEL 
Entity  Name:  Surface  Dim  3 SE  Rep 

Entity  Number:  INT-27 


Entity  Definition:  The  use  of  a "Surface  Model"  to  represent  a "Dimensionality  3 
Shape  Element".  A surface  model  has  no  information  for 
structuring  its  component  shells  into  solids.  So^  representation 
of  a "Dimensionality  3 Shape  Element"  by  a surface  model  is  a 
matter  of  human  interpretation,  rather  than  indigenous  content, 
of  the  data.  With  this  attitude,  a surface  model  may  represent 
any  category  of  "Dimensionality  3 Shape  Element". 


Business  Rules:  Eyery  "Surface  Dim  3 SE  Rep": 

• is  a "Dim  3 Shape  Element  Representation". 

• is  one,  and  only  one,  "Surface  Model". 

Primary  Key  Attributes: 


Shape  ID 

(FK) 

Shape  Elem  ID 

(FK) 

Dim  3 Rep  ID 

(FK) 

Other  Attributes: 

Surface  Model  ID 

(FK) 

SML: 


ENTITY  Surface-Dim-3-SE-Rep 

CATEGORY  BY  Dim-3-Rep-Type  OF  Dim-3-Shape-Element-Representation 
Surface-Model  "is  used  as"  NONULL 
ENDE 

EXPRESS: 


ENTITY  Surface_Dim_3_SE_Rep 

SUBTYPE  OF  ( Dim_3_Sbape_Element_Representation  ); 
Definition  : Surface_Model; 

END_ENTITY; 
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Ertity  Name: 
Entity  Number: 

Entity  Definition: 

Business  Rules: 


Section  1:  INTEGRATION  CORE  MODEL 
Surface  Model 
none 

Needs  to  be  defined  in  some  other  PDES  reference  model. 

Every  "Surface  Model": 

• is  a "Geometric  Model". 

• is  the  context  of  zero,  one,  or  more  "Surface  Area  Reps". 

• is  the  context  of  zero,  one,  or  more  "Surface  Dim  0 SE 
Reps". 

• is  used  as  zero,  one,  or  more  "Surface  Dim  3 SE  Reps". 

• is  the  context  of  zero,  one,  or  more  "Surface  NM  Area 
Reps". 

• is  the  context  of  zero,  one,  or  more  "Surface  Perimeter 
Reps". 

• is  ^e  context  of  zero,  one,  or  more  "Surface  Seam  Reps". 


Page  D3. 1.1-155 


ISO  TC184/SC4/WG1 


ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


N288 


Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name:  Surface  NM  Area  Rep 

Entity  Number:  INT-55 


Entity  Definition:  The  use  of  a "Subface"  in  a "Surface  Model"  to  represent  a 

"Nonmaximal  Area  Shape  Element".  In  a surface  model,  a 
subface  represents  a portion  of  surface  area  that  is  necessarily 
nonmaximal  because  the  subface  is  a subset  of  a face  with  a 
uniform  underlying  surface.  (Note:  The  IPIM  does  not  require 
that  a subface  be  a proper  subset  of  the  containing  face,  but  it 
seems  pointless  to  have  a subface  identical  to  its  containing  face. 
For  this  reason,  no  provision  is  made  here  for  representing  a 
"Maximal  Area  Shape  Element"  with  a subface.) 


Business  Rules:  Every  "Surface  NM  Area  Rep": 

• is  a "Nonmaximal  Area  Representation". 

• is  in  one,  and  only  one,  "Surface  Model”. 

• is  one,  and  only  one,  "Subface". 


Primary  Key  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Nonmax  Area  Rep  ID  (FK) 

Other  Attributes: 

Surface  Model  ID  (FK) 

Subface  ID  (FK) 


SML: 


ENTITY  Surf  a ce-NM- Area-Rep 

CATEGORY  BY  Nonmax-Area-Rep-Type 
OF  Nonmaximal- Area-Representation 
Subface  "is  used  as"  NONULL 
Surface-Model  "is  context  of  NONULL 
ENDE 
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Section  1:  INTEGRATION  CORE  MODEL 


EXPRESS: 


ENTITY  Surface_NM_Area_Rep 

SUBTYPE  OF  ( Nonmaximal_Area_Representation  ); 
Definition  : Subface; 

Context  : Surface_Model; 

END_ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 
Entity  Name:  Surface  Perimeter  Rep 

Entity  Number:  INT-75 


Entity  Definition:  The  use  of  a "Loop"  in  a "Surface  Model"  to  represent  a 

"Perimeter  Shap)e  Element".  In  a surface  model,  a loop  is 
employed  as  a boundary  of  a maximal  face.  Hence,  a loop  may 
represent  the  p>erimeter  of  an  "Area  Shape  Element". 

Business  Rules:  Eyery  "Surface  Perimeter  Rep": 

• is  a "Perimeter  Representation". 

• is  in  one,  and  only  one,  "Surface  Model". 

• is  one,  and  only  one,  "Loop". 


Primary  Key  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Perim  Rep  ID  (FK) 

Other  Attributes: 

Surface  Model  ID  (FK) 

Loop  ID  (FK) 


SML: 


ENTITY  Surface-Perimeter-Rep 

CATEGORY  BY  Perim-Rep-Type  OF  Perimeter-Representation 
Loop  "is  used  as"  NONULL 
Surface-Model  "is  context  of’  NONULL 
ENDE 

EXPRESS: 


ENTITY  Surface_Perimeter_Rep 

SUBTYPE  OF  ( Perimeter_Representation  ); 
Definition  : Loop; 

Context  : Surface_Model; 

END_ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 
Name:  Surface  Seam  Rep 


Entity  Numben  INT-65 

Entity  Definition:  The  use  of  an  "Edge"  in  a "Surface  Model"  to  represent  a "Seam 
Shape  Element",  to  a surface  model,  an  edge  is  employed  as  a 
boundary  element  of  a maximal  or  nonmaximal  face  and/or  as 
an  edge  of  a subface  of  a maximal  or  nonmaximal  face.  Eyen  if 
the  parent  face  is  maximal,  the  edge  may  be  nonmaximal;  i.e., 
the  edge  may  haye  an  adjacent  edge  wito  the  same  underlying 
curve.  So,  an  edge  may  represent  any  of  the  three  categories  of 
"Seam  Shape  Element"  - edge,  subedge,  or  interior  seam. 


Business  Rules:  Every  "Surface  Seam  Rep": 

• is  a "Seam  Representation". 

• is  in  one,  and  only  one,  "Surface  Model". 

• is  one,  and  only  one,  "Edge". 


Primary  Key  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Seam  Rep  ID  (FK) 

Other  Attributes: 

Surface  Model  ID  (FK) 

Edge  ID  (FK) 


SML: 


ENTITY  Surface-Seam-Rep 

CATEGORY  BY  Seam-Rep-Type  OF  Seam-Representation 
Edge  "is  used  as"  NONULL 
Surface-Model  "is  context  of  NONULL 
ENT)E 

EXPRESS: 

ENTITY  Surface_Seam_Rep 

SUBTYPE  OF  ( S€am_Representation  ); 

Definition  : Edge; 

Context  : Surface_Model; 

END_ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 
Entity  Name:  Unstruct  Geometry  Area  Rep 

Entity  Number:  E^JT-51 


Entity  Definition:  The  use  of  a "Geometry"  in  an  "Unstructured  Geometry  Model" 
to  represent  an  "Area  Shape  Element". 

Business  Rules:  Every  "Unstruct  Geometry  Area  Rep": 

• is  an  "Area  Representation". 

• is  in  one,  and  only  one,  "Unstructured  Geometry  Model". 

• is  one,  and  only  one,  "Geometry". 

Primary  Key  Attributes: 


Shape  ID 

(FK) 

Shap)e  Elem  ID 

(FK) 

Area  Rep  ID 

(FK) 

Other  Attributes: 


Unstruct  Geom  Model  ID  (FK) 
Geometry  ID  (FK) 


SML: 


ENTITY  Unstruct-Geometry-Area-Rep 

CATEGORY  BY  Area-Rep-Type  OF  Area-Representation 
Geometry  "is  used  as"  NONULL 

Unstructured-Geometry-Model  "is  context  of  NONULL 
ENDE 

EXPRESS: 


ENTITY  Unstruct_Geometry_Area_Rep 

SUBTYPE  OF  ( Area_Representation  ); 
Definition  : Geometry; 

Context ' : Unstructured_Geometry_Model; 
END.ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 


Entitv  Name: 

Unstruct  Geometry  Dim  0 SE  Rep 

Entity  Number: 

INT-90 

Entitv  Definition: 

The  use  of  a "Geometry"  in  an  "Unstructured  Geometry  Model" 
to  represent  a "Dimensionality  0 Shap>€  Element". 

Business  Rules: 

Every  "Unstruct  Geometry  Dim  0 SE  Rep": 

• is  a "Dim  0 Shape  Element  Representation". 

• is  in  one,  and  only  one,  "Unstructured  Geometry  Model". 

• is  one,  and  only  one,  "Geometry". 

Primary  Kev  Attributes: 

Shape  ID 

(FK) 

Shape  Elem  ID 

(FK) 

Dim  0 Rep  ID 

(FK) 

Other  Attributes: 


Unstruct  Geom  Model  ID  (FK) 
Geometry  ID  (FK) 


SML: 


ENTITY  Unstruct-Geometry-Dim-O-SE-Rep 

CATEGORY  BY  Dim-0-Rep-Typ>e  OF  Dim-O-Shape-Element-Representation 
Geometry  "is  used  as"  NONULL 

Unstructured-Geometry-Model  "is  context  of  NONULL 
ENDE 

EXPRESS: 


ENTITY  Unstruct_Geometry_Dim_0_SE_Rep 

SUBTYPE  OF  ( Dim_0_Shape_Element_Representation  ); 
Definition  : Geometry; 

Context  : Unstructured_Geometry_Model; 

END.ENTITY; 


Page  D3.1. 1-161 


ISO  TC184/SC4/WG1 


ANNEX  D 
(Draft  Proposal) 


November  22,  1988 


N2  8 8 


Sectxon  1:  INTEGRATION  CORE  MODEL 


Entity  Name:  Unstnict  Geometry  Dim  3 SE  Rep 

Entity  Number:  INT-29 


Entity  Definition:  The  use  of  a "Geometry"  in  an  "Unstructured  Geometry  Model" 
to  represent  a "Dimensionality  3 Shap)e  Element". 

Business  Rules:  Eyery  "Unstnict  Geometry  Dim  3 SE  Rep": 

• is  a "Dim  3 Shape  Element  Representation". 

• is  one,  and  only  one,  "Unstructured  Geometry  Model". 

Primary  Key  Attributes: 


Shape  ID 

(FK) 

Shape  Elem  ID 

(FK) 

Dim  3 Rep  ID 

(FK) 

Other  Attributes: 


Unstruct  Geom  Model  ID  (FK) 

SML: 

ENTITY  Unstruct-Geometry-Dim-3-SE-Rep 

CATEGORY  BY  Dim*3-Rep-Typ€  OF  Dim-3-Shape-Element-Representation 
Unstructured-Geometry-Model  "is  used  as"  NONULL 
ENDE 

EXPRESS: 


ENTITY  Unstruct_Geometry_Dim_3_SE_Rep 

SUBTYPE  OF  ( Dim_3_Sl^ape_Element_Representation  ); 
Definition  : Unstructured_Geometry_Model; 

END.ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 

Entity  Name: 

Unstruct  Geometry  Perimeter  Rep 

Entity  Number: 

INT-83 

Entity  Definition: 

The  use  of  a "Geometry"  in  an  "Unstructured 
to  represent  a 'Perimeter  Shape  Element". 

Geometry  Model' 

Business  Rules: 

Eyery  "Unstruct  Geometry  Perimeter  Rep": 

• is  a "Perimeter  Representation". 

• is  in  one,  and  only  one,  "Unstructured 

• is  one,  and  only  one,  "Geometry". 

Geometry  Model" 

Primary  Key  Attributes: 

Shape  ID 

(FK) 

Shape  Elem  ID 

(FK) 

Perim  Rep  ID 

Other  Attributes: 

(FK) 

Unstruct  Geom  Model  ID  (FK) 
Geometry  ID  (FK) 

SML: 


ENTITY  Unstruct-Geometry-Perimeter-Rep 

CATEGORY  BY  Perim-Rep-Type  OF  Perimeter-Representation 
Geometry  "is  used  as"  NONULL 

Unstructured-Geometry-Model  "is  context  of  NONULL 

ent:>e 

EXPRESS: 


ENTITY  Unstruct_Geometry_Perimeter_Rep 

SUBTYPE  OF  ( Perimeter_Representation  ); 
Definition  : Geometry; 

Context  : Unstructured_Geometry_Model; 
END.ENTITY; 
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Section  1:  INTEGRATION  COREMODEL 


Entity  Name:  Unstnict  Geometry  Seam  Rep 

Entity  Number:  INT-72 


Entity  Definition:  The  use  of  a "Geometry"  in  an  "Unstructured  Geometry  Model" 
to  represent  a "Seam  Shape  Element". 


Business  Rules:  Eyery  "Unstruct  Geometry  Seam  Rep": 

• is  a "Seam  Representation". 

• is  in  one,  and  only  one,  "Unstructured  Geometry  Model". 

• is  one,  and  only  one,  "Geometry". 


Primary  Key  Attributes: 


Shape  ID 

(FK) 

Shape  Elem  ID 

(FK) 

Seam  Rep  ID 

(FK) 

Other  Attributes: 

Unstruct  Geom  Model  ID 

(FK) 

Geometry  ID 

(FK) 

SML: 


ENTITY  Unstruct-Geometry-Seam-Rep 

CATEGORY  BY  Seam-Rei>Type  OF  Seam-Representation 
Geometry  "is  used  as"  NONULL 

Unstructured-Geometry-Model  "is  context  of"  NONULL 
ENDE 

EXPRESS: 

ENTITY  Unstruct_Geometry_Seam_Rep 

SUBTYPE  OF  ( Seam_Representation  ); 

Definition  : Geometry; 

Context  : Unstructured_Geometry_Model; 
END.ENTITY; 
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Entity  Name: 
Entity  Number: 

Entity  Definition: 

Business  Rules: 


Section  1:  INTEGRATION  CORE  MODEL 

Unstructured  Geometry  Model 

none 

Needs  to  be  defined  in  some  other  PDES  reference  model. 

Eyery  "Unstructured  Geometry  Model": 

• is  a "Geometric  Model". 

• is  the  context  of  zero,  one,  or  more  "Unstruct  Geometry 
Area  Reps". 

• is  the  context  of  zero,  one,  or  more  "Unstruct  Geometry 
Dim  0 SE  Reps". 

• is  used  as  zero,  one,  or  more  "Unstruct  Geometry  Dim  3 
SE  Reps". 

• is  the  context  of  zero,  one,  or  more  "Unstruct  Geometry 
NM  Area  Reps". 

• is  the  context  of  zero,  one,  or  more  "Unstruct  Geometry 
Perimeter  Reps". 

• is  the  context  of  zero,  one,  or  more  "Unstruct  Geometry 
Seam  Reps". 
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Entity  Name: 
Entity  Number: 

Entity  Definition: 

Bugines?  Rules: 


Section  1:  INTEGRATION  CORE  MODEL 


Vertex 

TOP-2 

Defined  in  the  PDES  Topology  reference  model. 

Eyery  "Vertex": 

• is  used  as  zero,  one,  or  more  "Brep  Dim  0 SE  Reps". 

• is  used  as  zero,  one,  or  more  "Full  Rev  SOR  Corner  Reps". 

• is  used  as  zero,  one,  or  more  "Full  Rev  SOR  Int  Loc  Reps". 

• is  used  as  zero,  one,  or  more  "Partial  Rev  SOR  Bdry  Loc 
Reps". 

• is  used  as  zero,  one,  or  more  "Peirtial  Rev  SOR  Comer 
Reps". 

• is  used  as  zero,  one,  or  more  'Partial  Rev  SOR  Int  Loc 
Reps". 

• is  used  as  zero,  one,  or  more  "SOLE  Dim  0 SE  Reps". 

• is  used  as  zero,  one,  or  more  "SOLE  Vertex  Seam  Reps". 

• is  used  as  zero,  one,  or  more  "Full  Rev  SOR  Vertex 
Perimeter  Reps". 

• is  used  as  zero,  one,  or  more  "SOR  Vertex  Seam  Reps". 

• is  used  as  zero,  one,  or  more  "Surface  Dim  0 SE  Reps". 

• is  used  as  zero,  one,  or  more  "Wireframe  Dim  0 SE  Reps". 
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Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name:  Voidless  Volume  Representation 

Entity  Number:  INT-34 


Entity  Definition:  The  symbolic  description  of  a "Voidless  Volume  Shape 
Element"  in  a "Geometric  Model". 


Business  Rules:  Every  "Voidless  Volume  Representation": 

• represents  one,  and  only  one,  "Voidless  Volume  Shape 
Element". 

• must  be  one,  and  only  one,  of  the  following: 

"Brep  Volume  Rep" 

"Full  Rev  SOR  Volume  Rep" 

"CSG  Primitive  Volume  Rep" 

"Facetted  Brep  Volume  Rep" 

"Half  Space  Volume  Rep" 

"Partial  Rev  SOR  Volume  Rep" 

"SOLE  Volume  Rep" 


Primary  Kev  Attributes: 

Shap>€  ID 
Shape  Elem  ID 
Volume  Rep  ID 


Other  Attributes: 


Volume  Rep  Type 


(FK) 

(FK) 

The  means  of  distinguishing  each  "Voidless 
Volume  Representation"  from  all  the  others  for  the 
same  "Voidless  Volume  Shape  Element". 


The  means  of  determining  whether  a "Voidless 
Volume  Representation"  is  a(n): 

"Brep  Volume  Rep", 

"Full  Rev  SOR  Volume  Rep", 

"CSG  Primitive  Volume  Rep", 

"Facetted  Brep  Volume  Rep", 

"Half  Space  Volume  Rep", 

"Partial  Rev  SOR  Volume  Rep",  or 
"SOLE  Volume  Rep". 
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SML: 

ENTITY  Voidless-Volume-Representation 
KEY 

Voidless-Volume-Shape-Element  "is  represented  by" 
Volume-Rep-ID 
ENDK 

Volume-Rep-Type  NONULL 
ENDE 

EXPRESS: 


ENTITY  Voidless_Volume_Representation 
SUPERTYPE  OF  ( Brep_Volume_Rep 

OR  Full_Rev_SOR_Volume_Rep 
OR  CSG_Primitive_Volume_Rep 
OR  Facetted_Brep_Volume_Rep 
OR  Half_Space_Volume_Rep 
OR  Partial_Rev_SOR_Volume_Rep 
OR  SOLE_Volume_Rep  ); 

END.ENTITY; 


N288 
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Section  1:  INTEGRATION  CORE  MODEL 
Entity  Name:  Voidless  Volume  Shape  Element 

Entity  Number:  INT-5 


Entity  Definition:  An  "Object  Shape  Element”  that  contains  no  voids. 

Business  Rules:  Every  "Voidless  Volume  Shape  Element"; 

• is  an  "Object  Shape  Element". 

• is  represented  by  zero,  one,  or  more  "Voidless  Volume 
Representations". 

Primary  Kev  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Other  Attributes:  none 


SML: 


ENTITY  Voidless-Volume-Shape-Element 

CATEGORY  BY  Object-SE-Type  OF  Object-Shape-Element 
ENDE 

EXPRESS: 


ENTITY  Voidless_Volume_Shape_Element; 

Representations  : LIST  OF  [ 0 : # ] OF  Voidless_Volume_Representation; 
END.ENTITY; 
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Entity  Name:  Wireframe  Area  Rep 


Entity  Number: 

INT-48 

Entity  Definition: 

The  use  of  a "Loop"  in  a "Wireframe  Model"  to  represent 
"Area  Shape  Element". 

Business  Rules: 

Eyery  'Wireframe  Area  Rep": 

• is  an  "Area  Representation". 

• is  in  one,  and  only  one,  'Wireframe  Model". 

• is  one,  and  only  one,  "Loop". 

Primary  Key  Attributes: 

Shape  ID 

(FK) 

Shape  Elem  ID 

(FK) 

Area  Rep  ID 

(FK) 

Other  Attributes: 

Wireframe  Model  ID  (FK) 

Loop  ID 

(FK) 

SML: 


ENTITY  Wireframe-Area-Rep 

CATEGORY  BY  Area-Rep-Type  OF  Area-Representation 
Loop  "is  used  as"  NONULL 
Wireframe-Model  "is  context  of"  NONULL 
ENDE 

EXPRESS: 

ENTITY  Wireframe_Area_Rep 

SUBTYPE  OF  ( Area_Representation  ); 
Definition  : Loop; 

Context  : Wireframe_Model; 

END_ENTITY; 
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Entity  Name: 
Entity  Number: 


Section  1:  INTEGRATION  CORE  MODEL 
Wireframe  Dim  0 SE  Rep 
INT-87 


Entity  Definition:  The  use  of  a "Vertex"  in  a "Wireframe  Model"  to  represent  a 
"Dimensionality  0 Shape  Element". 


Business  Rules: 


Every  "Wireframe  Dim  0 SE  Rep": 

• is  a "Dim  0 Shape  Element  Representation". 

• is  in  one,  and  only  one,  "Wireframe  Model". 

• is  one,  and  only  one,  "Vertex". 


Primary  Key  Attributes: 

Shape  ID 
Shape  Elem  ID 
Dim  0 Rep  ID 

Other  Attributes: 

Wireframe  Model  ID 
Vertex  ID 


(FK) 

(FK) 

(FK) 


(FK) 

(FK) 


SML: 


ENTITY  Wireframe-Dim-O-SE-Rep 

CATEGORY  BY  Dim-O-Rep-Type  OF  Dim-O-Shape-Element-Representation 
Vertex  "is  used  as"  NONULL 
Wireframe-Model  "is  context  of"  NONULL 
ENDE 

EXPRESS: 


ENTITY  Wireframe_Dim_0_SE_Rep 

SUBTYPE  OF  ( Dim_0_Shape_Element_Representation  ); 
Definition  : Vertex; 

Context  : Wireframe_Model; 

END.ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 


Entity  Name:  Wireframe  Dim  3 SE  Rep 

Entity  Number:  DJT-28 


Entity  Definition:  The  use  of  a "Wireframe  Model"  to  represent  a "Dimensionality 

3 Shape  Element". 

Business  Rules:  Eyery  'Wireframe  Dim  3 SE  Rep": 

• is  a "Dim  3 Shape  Element  Representation". 

• is  one,  and  only  one,  "Wireframe  Model". 


Primary  Key  Attributes: 


Shape  ID 

(FK) 

Shape  Elem  ID 

(FK) 

Dim  3 Rep  ID 

(FK) 

Other  Attributes: 

Wireframe  Model  ID 

(FK) 

5ML: 

ENTITY  Wireframe-Dim-3-SE-Rep 

CATEGORY  BY  Dim-3-Rep-Type  OF  Dim-3-Shape-Element-Representation 
Wireframe-Model  "is  used  as"  NONULL 
ENDE 

EXPRESS: 


ENTITY  Wireframe_Dim_3_SE_Rep 

SUBTYPE  OF  ( Dim_3_Shape_Element_Representation  ); 
Definition  : Wireframe_Model; 

END_ENTITY; 
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Section  1:  INTEGRATION  CORE  MODEL 
EnHH’’  Name:  Wireframe  Model 

Entity  Number:  none 

Entity  Definition:  Needs  to  be  defined  in  some  other  PDES  reference  model. 

Business  Rules:  Every  "Wireframe  Model": 

• is  a "Geometric  Model". 

• is  the  context  of  zero,  one,  or  more  'Wireframe  Area 
Reps". 

• is  the  context  of  zero,  one,  or  more  "Wireframe  Dim  0 SE 
Reps". 

• is  used  as  zero,  one,  or  more  'Wireframe  Dim  3 SE  Reps". 

• is  the  context  of  zero,  one,  or  more  Wireframe  NM  Area 
Reps". 

• is  the  context  of  zero,  one,  or  more  "Wireframe  Perimeter 
Reps". 

• is  the  context  of  zero,  one,  or  more  "Wireframe  Seam 
Reps". 
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Wireframe  Perimeter  Rep 


Entity  Number:  INT-76 


N288 


Entity  Definition:  The  use  of  a "Loop"  in  a "Wireframe  Model"  to  represent  a 

"Perimeter  Shape  Element". 

Business  Rules:  Eyery  "Wireframe  Perimeter  Rep": 

• is  a "Perimeter  Representation". 

• is  in  one,  and  only  one,  "Wireframe  Model". 

• is  one,  and  only  one,  "Loop". 


Primary  Key  Attributes: 


Shape  ID  (FK) 

Shape  Elem  ID  (FK) 

Perim  Rep  ID  (FK) 

Other  Attributes: 

Wireframe  Model  ID  (FK) 

Loop  ID  (FK) 


SML: 


ENTITY  Wireframe-Perimeter-Rep 

CATEGORY  BY  Perim-Rep-Type  OF  Perimeter-Representation 
Loop  "is  used  as"  NONULL 
Wireframe-Model  "is  context  of"  NONULL 
ENDE 

EXPRESS: 


ENTITY  Wireframe_Perimeter_Rep 

SUBTYPE  OF  ( Perimeter_Representation  ); 
Definition  : Loop; 

Context  : Wireframe_Model; 

END_ENTITY; 


f 
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Section  1:  INTEGRATION  CORE  MODEL 
Entity  Name:  Wireframe  Secim  Rep 

Entity  Number:  INT-66 

Entity  Definition:  The  use  of  an  "Edge"  in  a 'Wireframe  Model"  to  represent  a 
"Seam  Shape  Element". 


Business  Rules:  Eyery  Wireframe  Seam  Rep": 

• is  a "Seam  Representation". 

• is  in  one,  and  only  one,  'Wireframe  Model". 

• is  one,  and  only  one,  "Edge". 


Primary  Key  Attributes: 


Shape  ID 

(FK) 

Shape  Elem  ID 

(FK) 

Seam  Rep  ID 

(FK) 

Other  Attributes: 

Wireframe  Model  ID 

(FK) 

Edge  ID 

(FK) 

SML: 


ENTITY  Wireframe-Seam-Rep 

CATEGORY  BY  Seam-Rep-Type  OF  Seam-Representation 
Edge  "is  used  as"  NONULL 
Wireframe-Model  "is  context  of"  NONULL 
ENDE 

EXPRESS: 


ENTITY  Wireframe_Seam_Rep 

SUBTYPE  OF  ( Seam_Representation  ); 
Definition  : Edge; 

Context  : Wireframe_Model; 

END_ENTITY; 
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Entity  Name:  Zone  Shape  Element 

Entity  Number:  ENIT-ll 


Entity  Definition:  A "Dimensionality  2 Shape  Element"  that  is  the  union  of  other 

"Dimensionality  2 Shap>e  Elements". 

Business  Rules:  Eyery  "Zone  Shape  Element": 

• is  a "Dimensionality  2 Shape  Element". 

• consists  of  one  or  more  "Zone  Shape  Element 
Components". 


Primary  Key  Attributes: 


Shape  ID 

(FK) 

Shape  Elem  ID 

(FK) 

Other  Attributes: 

none 

SML: 

ENTITY  Zone-Shape-Element 

CATEGORY  BY  Dim-2-SE-Type  OF  Dimensionality-2-Shape-Element 
ENDE 

EXPRESS: 

ENTITY  Zone_Shape_Element 

SUBTYPE  OF  ( Dimensionality_2_Shape_Element  ); 
Components  : LIST  OF  [ 1 : # ] Zone_Shape_Element_Component; 
END.ENTITY; 
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Enritv  Name:  Zone  Shape  Element  Component 

Entity  Number:  INT-103 


Entity  Definition:  A "Dimensionality  2 Shape  Element"  that  is  part  of  a "Zone 
Shape  Element". 

Business  Rules:  Eyery  "Zone  Shape  Element  Component": 

• is  one,  and  only  one,  "Dimensionality  2 Shape  Element". 

• is  part  of  one,  and  only  one,  "Zone  Shape  Element". 

Primary  Key  Attributes: 


Shape  ID 
Zone  SE  ID 


Comp  SE  ID 


Other  Attributes: 


(FK) 

(FK)  — The  role  name  for  the  Shape  Elem  ID  of  the 
"Zone  Shape  Element"  that  includes  the  "Zone 
Shape  Element  Component". 

(FK)  - The  role  name  for  the  Shape  Elem  ID  of  the 
"Dimensionality  2 Shape  Element"  that  is  used  as 
the  "Zone  Shape  Element  Component". 

none 


SML: 


ENTITY  Zone-Shape-Element-Component 
KEY 

Zone-Shape-Element  "consists  of  P 
ROLE  Zone-SE-ID  FOR  Shape-Elem-ID 
Dimensionality-2-Shape-Element  "is  used  as" 
ROLE  Comp-SE-ID  FOR  Shape-Elem-ID 

ENDK 

ENDE 

EXPRESS: 


ENTITY  Zone_Shape_Element_Component; 
END.ENTITY; 
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ISO  TC184/SC4/WG1  ANNEX  D 

(Draft  Proposal 

SECTION  ^ NOMINAL  SHAPE  INFORMATION  MODEL 

2 NOMINAL  SHAPE  INFORMATION  MODEL 

2.1  Purpose 

This  document  presents  a conceptual  model  of  information  used  to  represent  nominal  shape.  This 
includes  geometry,  solids,  and  topology.  Geometry  includes  points,  curves,  and  surfaces.  Solids  is 
scope  down  to  the  two  most  popular  solid  representation  methods:  boundary  representation  (B-rep) 
and  constructive  solid  geometry  (CSG).  Topology  is  required  by  B-rep,  but  is  defined  independently 
from  B-rep.  The  intention  is  that  the  same  topology  entities  used  in  B-rep  can  be  used  for  other 
purposes  as  well. 

2.2  Method 

These  IDEFlX  models  were  developed  from  the  IPIM,  as  neither  the  Curves  & Surfaces  Committee 
nor  the  Solids  Committee  did  model  development  in  IDEFlX.  Care  has  been  taken  to  maintain 
conformity  between  the  IPIM  and  the  IDEFlX  by  using  the  same  names  and  words  as  much  as 
possible.  There  are  two  major  departures  from  this  philosophy,  however.  The  first  is  that  common 
attributes  are  not  migrated  to  the  leaf  entities  as  in  the  IPIM.  Instead  the  common  attributes  appear 
in  the  appropriate  supertype.  The  second  is  that  “coordinated  lists”  are  not  used  here.  Instead 
new  entities  were  created  to  bundle  the  coordinated  elements  together  explicitly.  For  example 
SEGMENT/GEO-44  bundles  the  elements  from  the  COMPOSITE-CURVE/GEO-33  attributes 
“segments”  and  “senses”. 


October  31,  1988 


2.3  GEOMETRY 

Entity  Name;  GEOMETRY 

Entity  Number;  GEO-1 

This  the  supertype  of  all  geometric  entities. 

Primary  Key  Attributes 

GEOMETRY  JD 

Other  Attributes 

GEOMETRY -TYPE  (discriminator)  ' 

Business  Rules 

EXPRESS  Specification 

ENTITY  geometry 


7 


ISO  TC184/SC4/WG1  ANNEX  D 

(Draft  Proposal 

SECTION  NOMINAL  SHAPE  INFORMATION  MODEL 

SUPERTYPE  OF  (point  XOR 
vector  XOR 
axis.placement  XOR 
transf ormation.matrix  XOR 
curve  XOR 
surface) 

END. ENTITY; 

Entity  Name:  POINT 

Entity  Number:  GEO-2 

A point  is  a location  in  some  coordinate  space. 

Primary  Key  Attributes 

POINT  JD 

Q t h er  Attributes 

POINT  TYPE  (discriminator) 

Business  Rules 
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EXPRESS  Specification 
ENTITY  point 

SUPERTYPE  OF  (cartesian.point  XOR 
point.on.curve  XOR 
point. on. surf ace) 
SUBTYPE  OF  (geometry); 

END. ENTITY; 


Entity  Name:  VECTOR 

Entity  Number:  GEO-3 

Collects  the  two  types  of  vector:  DIRECTION/GEO-14  and 
VECTOR-WITHJdAGNITUDE/GEO-17. 

Primary  Key  Attributes 

VECTOR  ID 


8 


ISO  TC184/SC4/WG1 


ANNEX  D 
(Draft  Proposal) 


October  31,  1988 


N288 


Section  2:  NOMINAL  SHAPE  INFORMATION  MODEL 


Other  Attributes 

V'’ECTOR.T'iTE  (discriminator) 

Business  Rules 


EXPRESS  Specification 

ENTITY  vector 

SUPERTYPE  OF  (diraction  XOR 

v«ctor_¥ith.magnitud®) 
SUBTYPE  OF  (geometry): 

END.ENTITY; 


Entity  Name;  AXIS  J>LACEMENT 
Entity  Number:  GEO-4 

The  local  environment  for  definition  of  a geometry  entity.  It  locates  the  entity  to  be  defined  and 
gives  its  orientation. 

Primary  Key  Attributes 
AXISJ>LACEMENT-ID 

Other  Attributes 

AXIS  -PLACEMENT.T^TE  (discriminator) 

CARTESIAN  POINT  JD  (FK) 

The  location. 

AXIS.DIRECTIONJD  (FK) 

Direction  of  local  Z axis. 

Business  Rules 


EXPRESS  Specification 

ENTITY  axis. placement 

SUPERTYPE  OF  (axisl.placement  XOR 
axis2. placement) 
Sl^TYPE  OF  (geometry): 

END. ENTITY: 
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Entity  Name!  TRANSFORMATION-MATRIX 
Entity  Number;  GEO-5 

A gfometric  transformation  including  tranilation,  rotation,  mirroring  and  scaling. 

Primary  Key  Attributes 
TRANSFORMATION  -MATRIX  .ID 

Other  Attributes 

AXlSl.THREE.SPACE-DrRECTIONJD  (FK) 

The  approximate  direction  of  the  reqtiired  X axis. 

AXIS2. THREE. SPACE  DIRECTIONTD  (FK) 

The  approximate  direction  of  the  required  Y axis. 

AXIS3  THREE  SPACE  DIRECTION  ID  (FK) 

The  exact  direction  of  the  required  Z axis. 

CARTESIAN J’OINTJD  (FK) 

The  required  translation. 

SCALE 

Number  Talue  of  scaling  factor. 

Business  Rules 


EXPRESS  Specification 


ENTITY  transformation 
SUBTYPE  OF  (geometry) ; 
axisl  : OPTIONAL 

axi62  : OPTIONAL 

axisS  : OPTIONAL 

local. origin  : OPTIONAL 

scale  : OPTIONAL 

END. ENTITY: 


three. space. direction ; 
three. space. direction : 
three. space. direction ; 
cartesian. point : 

REAL; 


Entity  Name;  CURVE 
Entity  Number;  GEO-6 
The  class  of  all  curves. 
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Primarv  Kev  Attributes 
CURVE  JD 

Other  Attributes 
CURVE-T'iTE  (discriminator) 

Business  Rules 

EXPRESS  Specification 

ENTITY  curve 

SUPERTYPE  OF  (line  lOR  conic  lOR  bounded.curve  lOR 
corve.on.surface  XOR  olfaet. curve) 
SUBTYPE  OF  (geometry); 

END.ENTITY: 


Entity  Name;  SURFACE 
Entity  Number;  GEO-7 

The  general  class  of  all  surfaces. 

Primary  Key  Attributes 
SURFACEJD 

Q t h e_r _A  ttributes 
SURFACE.TYPE  (discriminator) 

Business  Rules 

EXPRESS  Specification 
ENTITY  surface 

SUPERTYPE  OF  (elementary.aurf ace  XOR  ssept.surface  XOR 
bounded.surface  XOR  off set. surf ace  XOR 
r ect angular .compos ite.aurf ace) 

SUBTYPE  OF  (geometry): 

END.ENTITY: 
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Entity  Name:  CARTESIAN_POINT 

Entity  Number;  G£0«8 
A point  defined  in  a cartesian  coordinate  system. 

Primary  Key  Attributes 
CARTESIAN  J>OINTJD 

Other  Attributes 

CARTESIAN-POINT.TYPE  (discriminator) 

X-COORDINATE 

Y.COORDINATE 

Business  Rules 

EXPRESS  Specification 

ENTITY  cartesian.point 

SUPERTYPE  OF  (cartesian.two.coordinate  lOR 
cartas I an.chraa. coordinate) 

SUBTYPE  OF  (point): 

END. ENTITY; 

Entity  Name;  CARTESIAN.TWO.POINT 
Entity  Number:  GEO-10 

A point  defined  in  two  dimensional  Euclidean  space. 

Primary  Key  Attributes 
CARTESIAN.TWOJ»OINTJD 

Other  Attributes 

Business  Rules 
EXPRESS  Specification 

ENTITY  cartesian.tBo. coordinate 
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SwBTTPE  OF  point) : 

i_coordinat«  : REAL; 

;_coordinat«  : REAL; 

EN'D.EJ.’TITY; 

Entity  Name;  CARTESIAN-THREE-POINT 
Entity  Number;  GEO-11 

A point  deHned  in  three  dimensional  Euclidean  space. 

Primary  Key  Attributes 

CARTESIAN-THREE.COORDINATEJD 

Other  Attributes 

Z-COORDINATE 

Business  Rules 

EXPRESS  Specification 

ENTITY  cartes ian.thrae. coordinate 
SUBTYPE  OF  (cartesian.point) ; 

X. coordinate  : REAL; 

y.  coordinate  : REAL; 

z. coordinate  : REAL; 

END. ENTITY; 


Entity  Name;  POINT.ON. CURVE 

Entity  Number:  GEO-12 

A point  located  in  the  parametric  space  of  a curve. 

Primary  Key  Attributes 

POENT.ON.CURVEJD 

Other  Attributes 

CURVEJD  (FK) 


POLNT_PARAMETER 

The  parametric  value  of  the  point. 


ISO  TC184/SC4/WG1 


ANNEX  D 
(Draft  Proposal) 


October  31,  1988 


N28! 


Section  2:  NOMINAL  SHAPE  INFORMATION  MODEL 


Business  Rules 

EXPRESS  Specification 

ENTITY  point. on. curve. coordinat# 
SUBTYPE  OF  (point); 
basis. curve  : curve; 
point. paraoeter  : REAL; 
END.ENTITY; 


Entity  Name:  POINT.ON^URFCAE 

Entity  Number;  GEO*  13 
A point  located  in  the  parametric  space  of  a surface. 

Primary  Key  Attributes 
POINT.ON^URFACEJD 

P t h e_r _At_t  ri  b.ules 

SURFACEJD  (FK) 

POINT  PARAMETER.! 

The  first  parameter  value  of  the  point  location 

P0INT_PARAMETERJ2 

The  second  parameter  value  of  the  point  location. 

Business  Rules 

EXPRESS  Specification 

ENTITY  point. on. surf ace 
SUBTYPE  OF  (point); 
basis. surf ace  : surface; 
point. parameter.!  : REAL; 
point. parameter. 2 : REAL; 

END.ENTITY; 

Entity  Name:  DIRECTION 

Entity  Number;  GEO- 14 
A geometric  direction. 
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Primary  Key  Attributes 

DIRECTION  ID 

Other  Attributes 
DERECTION.TYPE  (discriminator) 

X 

The  direction  ratio  with  respect  to  the  X axis. 
Y 

The  direction  ratio  with  respect  to  the  Y axis. 
Business  Rules 


EXPRESS  Specification 
ENTITY  direction 

SUPERTYPE  OF  (two. space. direction  lOR  three. space. direction) 
SUBTYPE  OF  (vector): 

END. ENTITY; 


Entity  Name;  TWO-SPACE-DIRECTION 
Entity  Number;  GEO-15 
A direction  vector  in  Euclidean  two  space. 

Primary  Key  Attributes 
TWO-SPACE-DIRECTION-ID 

Other  Attributes 

None 

Busin  ess  Rules 


EXPRESS  Specification 

ENTITY  two. space. direction 
SUBTYPE  OF  (direction) ; 

X ; REAL: 
y : REAL: 
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END.EKTITT; 

Entity  Name;  THREE  ^PACEJ^IRECTION 

Entity  Number;  GEO*16 
A direction  vector  in  EucLde&n  three  space. 

Primary  Key  Attributes 
THREE-SPACE-DIRECTIONJD 

Other  Attributes 

Z 

The  direction  ratio  with  respect  to  the  Z axis. 
Business  Rules 


EXPRESS  Specification 

ENTITY  three. space.direction 
SUBTYPE  OF  (direction); 

X : REAL: 
y : REAL: 
z : REAL: 

END.ENTITY; 

Entity  Name;  VECTOR.WITH  J4AGNITUDE 

Entity  Number:  GEO- 17 
A direction  vector  and  the  magnitude  of  the  vector. 

Primary  Key  Attributes 
VECTOR-WTTH-MAGNTTUDEJD 

Other  At  tributes 

DIRECTION  ID  (FK) 

The  orientation. 

MAGNITUDE 

Real  ■v'alue  which  is  the  magnitude  of  the  vector. 
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Business  Rules 

EXPRESS  Specification 

ENTITY  v«ctor.»ith_sagnitud« 
SUBTYPE  OF  (vector); 
orientation  : direction; 
sagnitude  : REAL; 

END. ENTITY; 

Entity  Name;  AXISl-PLACEMENT 

Entity  Number;  GEO-IS 

An  8jd symmetric  local  coordinate  system. 

Primary  Key  Attributes 

AXISl-PLACEMENTJD 

Other  Attributes 

None 

Business  Rules 


EXPRESS  Specification 

ENTITY  axisl.placement 

SUBTYPE  OF  (ajcis.plaeement) ; 
location  : point; 
axis  : OPTIONAL  direction; 
END. ENTITY; 


Entity  Name;  AXIS2_PLACEMENT 

Entity  Number;  GEO- 19 

A complete  local,  cartesian  coordinate  system. 

Primary  Key  At t ributes 
AXIS2J>LACEMENTJD 
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Other  Attributes  j 

REF. DIRECTION. ID  (FK) 

The  approximate  direction  of  the  local  X axil. 

Business  Rules  i 

i 

EXPRESS  Specification 

■I 

ENTITY  axiB2.plac«in«nt 

SUBTYPE  OF  (axis.placamant) ; . 

location  : point;  [ 

axis  : OPTIONAL  direction;  i 

ref .direction  : OPTIONAL  direction; 

END. ENTITY; 

Entity  Name;  LINE 
Entity  Number;  GEO-20 

An  unbounded  straight  line.  The  positive  direction  of  the  line  is  in  the  positive  direction  of  its  ! 
direction  vector. 

Primary  Key  Attributes 
LINEJD 

Other  Attributes 
CARTESIAN -POINT  JD  (FK) 

Location  of  the  Line.  ^ 

DIRECTIONJD  (FK) 

The  direction  of  the  line. 

B usiness  Rules 

EXPRESS  Specification 

ENTITY  line 

SUBTYPE  OF  (curve); 
pnt  : point; 
dir  : direction; 

END. ENTITY; 
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~E«tity  Name;  CONIC 
Entity  Numbers  CEO«21 

A OTUcal  curve.  Namely  a drde,  eDipie,  hyperbola,  or  parabola. 

Primary  Key  Attributes 

CONIC  JD 

Other  Attributes 

CONIC.TYPE  (ditcrimmator) 

AXIS2J»LACEMENTJD  (FK) 

The  location  and  orientation  of  the  conic. 

Business  Rules 

EXPRESS  Specification 

ENTITY  conic 

SUPERTYPE  OF  (circle  XOR  ellipse  lOR  hyperbola  XOR  parabola); 
SUBTYPE  OF  (curve) ; 

END.ENTITY; 


Entity  Name;  BOUNDED.CURVE 
Entity  Number:  GEO*22 

A class  of  curves  with  hnite  length.  The  length  may  be  Enite  naturally  (as  a circle)  or  Unite  due 

to  trimming. 

Primary  Key  Attributes  _ 

BOUNDED  CURVEJD 

Other  Attributes 

BOUNDED-CURVE-TYPE  (discriminator) 
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Business  Rules 


EXPRESS  Specification 

ENTITT  bound«d_curv® 

SUPERTTPE  OF  (lin«.f«gn«nt  ZOR  b«zi«r.car7«  ZOR  b.cplin®. curve  ZOR 
trinmed. curve  ZOR  composite.curve) ; 

SUBTYPE  OF  (curve); 

END. ENTITY; 


Entity  Name;  CURVE.ON.SURFACE 
Entity  Number;  GEO>23 

The  class  of  curves  whose  members  are  restricted  to  being  contained  in  a specified  surface. 

Primary  Key  Attributes 
CURVE-ON-SURFACEJD 

Other  Attributes 

CURVE. ON. SURFACE -T'iTE  (discriminator) 

Business  Rules 


EXPRESS  Specification 
ENTITY  curve.on.aurf ace 

SUPERTYPE  OF  (pcurve  ZOR  surface. curve  ZOR  intereection. curve 
ZOR  composite. curve. on.surface) ; 

SUBTYPE  OF  (curve); 

END.ENTITY; 


Entity  Name;  OFF-SET 

Entity  Number;  GEO*24 

A curve  a constant  distance  from  a basis  nirve. 

Primary  Key  Attributes 
OFFSET.CURVEJD 


20 


ISO  TC184/SC4/WG1 


ANNEX  D 
(Draft  Proposal) 


October  31,  1988 


N288 


Section  S:  NOMINAL  SHAPE  INFORMATION  MODEL 


Other  Attributes 

CURVE  ID  (FK) 

The  ciuve  that  is  being  offset. 

DISTANCE 

The  distance  of  the  offset  from  the  basis  curve. 
SELFJNTERSECTION 

Three  value  flag  to  indicate  whether  curve  self  intersects; 
TRUE 

Curve  does  self  intersect. 

FALSE 

Curve  does  not  self  intersect. 

UNDEFINED 

WTiether  curve  self  intersects  or  not  is  unknown. 
OFFSET. CURVE.TYPE  (discriminator) 

Business  Rules 

EXPRESS  Specification 

ENTITY  offaet.curva 

SUPERTYPE  OF  (d2.off set. curve  XOR  d3.off set. curve) 
SUBTYPE  OF  (curve); 

END.ENTITY; 

Entity  Name;  CIRCLE 
Entity  Number:  GEO'25 
A complete  circle. 

Primary  Key  Attributes 

CIRCLEJD 

Other  Attributes 

RADIUS 

Real  number  value  which  is  the  radius  of  the  circle. 
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Business  Rules 

EXPRESS  Specification 

ENTITY  circl«; 

SUBTYPE  OF  (conic); 
radius  : REAL: 
position  : azi82.plac«m«nt ; 
END.ENTITY; 

Entity  Name;  ELLIPSE 

Entity  Number;  GEO>26 

A complete  ellipse. 

Primary  Key  Attributes 
ELLIPSEJD 

Other  Attributes 

SEMI-A.XIS.1 

Real  number  value  which  is  the  major  radius. 
SEMIJ^XISJ? 

Real  number  value  which  is  the  minor  radius. 
Business  Rules 


EXPRESS  Specification 

ENTITY  allipsa; 

SUBTYPE  OF  (conic); 
semi. axis. 1 : REAL; 
semi. axis. 2 : REAL; 
position  : axis2_placaoent ; 
END.ENTITY; 

Entity  Name;  HYPERBOLA 

Entity  Number;  GEO-27 
An  unbounded  hyperbola. 
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PrimBTy  Key  Attributes 

HYPERBOLAJD 

Other  Attributes 

SEMI -AXIS 

Real  number  value  which  is  the  length  of  the  “major  radius”  of  the  hyperbola. 
SEMUMAG-AXIS 

Real  number  value  which  is  the  length  of  the  “minor  radius”. 

Business  Rules 

EXPRESS  Specification 

ENTITY  hyperbola; 

SUBTYPE  OF  (conic); 
semi.axis  : REAL; 

semi. imag. axis  : REAL; 
position  : azi62. placement ; 

END.ENTITY; 

Entity  Name;  PARABOLA 
Entity  Number;  GEO-28 
An  imbounded  parabola. 

Primary  Key  Attributes 

PARABOLA -ID 

Other  Attributes 

FOCAL  JDIST 

Real  number  value  which  is  the  distance  of  the  focal  point  from  the  vertex  point. 
Business  Rules 


EXPRESS  Specification 

ENTITY  parabola: 
SUBTYPE  OF  (conic); 
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foc&I.dist  : REAL; 

position  : azis2.pl»c«D«nt ; 

END.ENTITY; 


Entity  Name;  LINE^EGMENT 
Entity  Number;  GEO*29 

A straight  line  segment.  This  entity  is  included  for  efficiency.  Alternately  a 
TRIMMED-CURVE/GEO-32  trimming  a LINE/GEO-20  could  be  used. 

Primary  Key  Attributes 

LINE^EGMENTJD 

Other  Attributes 

FIRST. POINT  JD  (FK)  The  starting  location  of  the  line  segment. 

SECOND. POINT  JD  (FK)  The  ending  location  of  the  line  segment. 

B usiness  Rules 

EXPRESS  Specification 

ENTITY  line.segrient 

SUBTYPE  OF  (bounded. curve ) ; 
lirst.point  : cartesian.point ; 

last.point  : cartesian.point; 

END.ENTITY; 

Entity  Name;  BEZIER.CURVE 
Entity  Number:  GEO-30 

A Bezier  curve.  It  should  be  noted  that  every  Bezier  curve  has  an  equivalent  representation  as  a 
B-spline  curve,  but  not  every  B-spline  curve  can  be  represented  as  a single  Bezier  curve. 

Primary  Key  Attributes 

BEZIER  CURVE  JD 
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Other  Attributes 

RATIONAL 

Logical  iralue  which  indicatei  whether  the  cmre  ii  rational  (TRUE)  ©r  iimple  polynomial 
(FALSE). 

UNIFORM 

Logical  value  which  indicates  whether  the  knot  set  is  uniform  (TRUE)  or  not  uniform  (FALSE). 
DEGREE 

Integer  value  which  is  the  algebraic  degree  of  the  basis  functions. 

FORMJNUMBER 

Symbol  used  to  identify  particular  type  of  aixve. 

SELFJNTERSECTION 

Three  value  flag  to  indicate  whether  curve  seif  intersects: 

TRUE 

Curve  does  self  intersect. 

FALSE 

Curve  does  not  self  intersect. 

UNDEFINED 

Whether  curve  self  intersects  or  not  is  unknown. 

Business  Rules 


EXPRESS  Specification 


ENTITY  bezier. curve 

SUBTYPE  OF  (bounded.curve) ; 


rational 

degree 

eontrol.points 
veights 
lorffi.nuaber 
self .intersect 
END.ENTITY; 


LOGICAL; 

INTEGER: 

ARRAY  [0:k]  OF  cartes i an.point ; 
OPTIONAL  ARRAY  {0:k}  OF  REAL; 
OPTIONAL  bspline. curve. form; 
true.f all e.or.undef ined ; 


Entity  Name;  B -SPLINE-CURVE 
E^ti^  Number;  GEO-31 

A b-spHne  curve.  The  b*spline  may  be  either  rational  or  not  rational. 
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Primary  Key  Attributes 

B. SPLINE -CURVE  JD 

Other  Attributes 

RATIONAL 

Logical  value  which  indicates  whether  the  curve  is  rational  (TRUE)  or  simple  polynomial 
(FALSE). 

UNIFORM 

Logical  value  which  indicates  whether  the  knot  set  is  uniform  (TRUE)  or  not  uniform  (FALSE). 
DEGREE 

Integer  value  which  is  the  algebraic  degree  of  the  basis  functions. 

FORM -NUMBER 

Enumeration  selection  used  to  identify  the  particular  type  of  curve. 

SELF  INTERSECTION 

Three  value  flag  to  indicate  whether  curve  self  intersects: 

TRUE 

Curve  docs  self  intersect. 

FALSE 

Curve  does  not  self  intersect. 

UNDEFINED 

Whether  curve  self  intersects  or  not  is  unknown. 

Business  Rules 


EXPRESS  Specification 


ENTITY  b-splino. curve 

SUBTYPE  OF  (bounded. curve) ; 


rational 

uniform 

degree 

control. points 
weights 
f orm.number 
self. intersect 

END. ENTITY: 


LOGICAL; 

LOGICAL: 

INTEGER; 

ARRAY  [0:f]  OF  cartesian. point ; 
OPTIONAL  ARRAY  {0:f}  OF  REAL; 
OPTIONAL  bspline. curve. form; 
true.false.or.undef ined; 
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Entity  Name;  TRIMMED.CURVE 
Entity  Number;  GEO>32 
A portion  of  a curve. 

Primary  Key  Attributes 

TRIMMED  CURVE  JD 

Other  Attributes 

TRIMMED -CURVE-T'iTE  (discriminator) 

CURVEJD  (FK) 

Curve  being  trimmed. 

SENSE 

Logical  value  which  indicates  whether  the  curve  is  being  traversed  in  the  direction  of  increasing 
parametric  value  (TRUE)  or  decreasing  parametric  value  (FALSE). 

Business ^ules  * 


EXPRESS  Sp ecification 

ENTITY  trimmed.curve 

SUBTYPE  OF  (boundad.curva) ; 

basis. curve  : curve; 

paraineter.l  : OPTIONAL  REAL; 

parasieter.2  : OPTIONAL  REAL; 

point. 1 : OPTIONAL  cartasian.point ; 

point_2  : OPTIONAL  cartasian.point; 

sense  : LOGICAL; 

END.ENTITT; 


Entity  Name;  COMPOSITE-CURVE 
Entity  Number;  G£0*33 
A collection  of  curves  joined  end  to  end. 

Primary  Key  Attributes 

COMPOSITE.CURVEJD 
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Other  Attributes 

CLOSED  CURVE 

Logical  value  which  indicates  whether  the  curve  it  doted  (TRUE)  or  open  (FALSE). 
SELFJNTERSECTION 

Three  value  flag  to  indicate  whether  curve  self  intersects: 

TRUE 

Curve  does  self  intersect. 

FALSE 

Curve  does  not  self  intersect. 

UNDEFINED 

Whether  curve  self  intersects  or  not  is  unknown. 

Business  Rules 


EXPRESS  Specification 


ENTITY  composite.curve 

SUBTYPE  OF  ( bounded. curve ) ; 


closed. curve 
segments 
senses 
transitions 
param. range 
END. ENTITY; 


LOGICAL; 

LIST  [l:t]  OF  bounded.curve ; 

ARRAY  [l;f]  OF  LOGICAL: 

ARRAY  [l:i]  OF  curve.transition.code ; 
OPTIONAL  ARRAY  [l:i]  OF  REAL; 


Entity  Name:  CONTROL  JOINT  JEZIER 

ErUit^^Numben  GEO«34 
A control  point  a BEZIER-CURVE/GEO-30. 

Primary  Key  Attributes 
BEZIER-CURVTJD  (FK) 

CONTROL -POINT  BEZIER  JD 

Other.Attributej 
CARTESIAN BOINTJD  (FK) 


WEIGHTS 

Real  number  value  of  weight  associated  with  this  control  point. 
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Business  Rules 
EXPRESS  Specification 

Se«  attribute  “control^oints”  m EXPRESS  for  BEZIER-CURVE/GEO-30. 

Entity  Name;  CONTROL-POINT-ORDER_BEZIER 

Entity  Number;  GEO>35 

IDEFIX  defaults  to  unordered  sets.  This  entity  makes  CONTROL  J*OINT-BEZIER/GEO-34 
ordered  list. 

Primary  Key  Attributes 
BEZIER.CURVE  JD  (FK) 

PREDECESSOR.CONTROLJ>OINT-BEZIER  (FK) 

SUCCESSOR. CONTROL-POINT_BEZIER  (FK) 

Qther_  Attributes 
None 

Business  Rules 
EXPRESS  Specification 

See  attribute  “control.points”  in  EXPRESS  for  BEZIER-CURVE/GEO-30. 

Entity  Name:  KNOT 

Entity  Number;  G£0>36 
A knot  for  a B^PLINE.CURVE/GEO-31. 

Primary  Key  Attributes 

B. SPLINE  CURVE JD  (FK) 

KNOTJD 


an 
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Other  Attributes 

MULTIPLICITY 

Integer  value  of  multiplicity  of  this  knot. 

KNOT-VALUE 

Real  number  value  of  this  knot  which  is  one  of  a set  of  knots  used  to  define  the  B-spline  basis 

function. 

Business  Rules 
EXPRESS  Specification 

See  attributes  “knots"  and  “knot  jnultiplicities”  in  the  EXPRESS  for  B. SPLINE -CURVE/GEO-31. 
Entity  Name:  CONTROL  J»OINT 

Entity  Number;  GEO*37 
A control  point  for  a B.SPLINE.CURVE/GEO-31. 

Primary  Key  Attributes 

B SPLINE. CURVE -ID  (FK) 

CONTROL -POINT  JD 

Other  Attributes 
CARTESIAN.POINTJD  (FK) 

WEIGHTS 

Real  number  value  of  weight  associated  with  this  control  point. 

Business  Rul « 

EXPRESS  Specification 

See  attributes  “controLpoints”  and  “weights”  in  the  EXPRESS  for  B-SPLINE-CURV'E/GEO-31. 
Entity  Name;  CONTROL-POINT.ORDER 

Entity  Number;  GEO*38 

IDEFlX  defaults  to  unordered  sets.  This  entity  makes  CONTROL.POINT/GEO-37  an  ordered 
list. 
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Primary  Key  Attributes 
B. SPLINE -CURVE  ID  (FK) 

PREDECESSOR.CONTROL POINTJD  (FK) 

SUCCESSOR.CONTROL J>OINTJD  (FK) 

Oth er  Attributes 
None 

Business  Rules 
EXPRESS  Specification 

See  attributes  “control  points”  and  “weights”  in  the  EXPRESS  for  B SPLINE  CURVE/GEO-31. 
Entity  Name;  POINT J*OINT_TRIMMED.CURVE 

Entity  Number;  GEO*39 
A curve  trimmed  with  two  cartesian  points. 

Primary  Key  Attributes 

TRIMMED  CURVE  ID  (FK) 

Other  Attributes 
POINT.l. CARTESIAN-POINT JD  (FK) 

P0INT.2  CARTESIAN ROINT.ID  (FK) 

B-U siness  Rii le s 

EXPRESS  Specification 

See  the  EXPRESS  for  TRIMMED.CURVE/GEO-32. 

Entity  Name;  POINT  JARAM.TRIMMED. CURVE 

Entity  Number;  GEO>40 

A curve  trimmed  with  one  cartesian  point  and  one  parametric  point. 
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; 

: 

Primary  Key  Attributes 

TRIMMED.CURVEID  (FK)  | 

Other  Attributes  ! 

CARTESIAN  POINT  JD  (FK) 

First  trimming  point. 

PARAMETERS 

Real  number  value  which  is  the  second  trimming  point  in  the  parametric  space  of  the  basis 
curve. 


B usi ness.  Rules 

EXPRESS  Specification 

See  the  EXPRESS  for  TRIMMED.CURVE/GEO-32. 

Entity  Name:  PARAM-POINT.TBJMMED -CURVE 

Entity  Number;  GEO*41 

A curve  trimmed  with  one  cartesian  point  and  one  parametric  point. 

Primary  Key  Attributes 

TRIMMED-CURVEJD  (FK)  j| 

Other  Attributes 

PARAMETER.! 

Real  number  value  which  is  the  first  trimming  point  in  the  parametric  space  of  the  basis 
curve. 

CARTESIAN  J>OINTJD  (FK)  ‘ 

Second  trimming  point . 

B u si  ness  Rules  | 

EXPRESS  Specification  V 

See  the  EXPRESS  for  TRIMMED-CURVE/GEO-32.  | 

Entity  Name;  PARAM-PARAM.TRIMMED -CURVE 

Entity  Number:  GEO>42 

A curve  trimmed  with  two  parametric  values.  j 

1 
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Primary  Key  Attributes 
PARAMETER.! 

Real  Dumber  ralue  which  it  the  iint  trimming  point  in  the  parametric  space  of  the  basis 
curve. 

PARAMETERS 

Real  niunber  value  which  is  the  second  trimming  point  in  the  parametric  space  of  the  basis 
curve. 

Other  Attributes 

None 

Business  Rul gs 

EXPRESS  Specification 

See  the  EXPRESS  for  TR[MMED.CURVE/GEO-32. 

Entity  Name;  KNOT-ORDER 

Entity  Number;  GEO*43 

IDEFIX  defaults  to  unordered  sets.  This  entity  makes  KNOT/GEO-36  an  ordered  list. 

Primary  Key  Attributes 

B SPLINE  CURVE  JD  (FK) 

PREDECESSOR.KNOTJD  (FK) 

SUCCESSOR.KNOTID  (FK) 

Other  Attributes 

None 

Business  Rules 
EXPRESS  Specification 

See  attributes  “control-points"  and  “weights”  in  the  EXPRESS  for  B_SPLINE-CURV^E/GE0-31. 
Entity  Name:  SEGMENT 

Entity  Number;  GEO-44 

A component  curve  of  a COMPOSITE.CURV'E/GEO-33. 
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Primary  Key  Attributes 
COMPOSITE-CURVEJD  (FK) 

SEGMENT  JD 

Other  Attributes 

BOUNDED. CURVE  JD  (FK) 

A component  curre. 

SENSE 

Logical  value  which  indicates  whether  the  sense  of  component  curve  agrees  or  differs  from  the 
sense  of  the  composite  curve. 

Business  Rules 
EXPRESS  Specification 

See  attribute  “segments”  in  EXPRESS  for  COMPOSITE.CURVE/GEO-33. 

Entity  Name;  SEGMENT-ORDER 

Entity  Number;  GEO>45 

IDEFlX  defaults  to  unordered  sets.  This  entity  makes  SEGMENT/GEO-44  an  ordered  Lst. 

Pji m ary  _K  ey_A  1 1 rib  u tes 
COMPOSITE-CURVEJD  (FK) 

PREDECESSOR.SEGMENTJD  (FK) 

SUCCESSOR.SEGMENTID  (FK) 

Other  Attributes 

TRANSITION 

Enumeration  selection  for  form  of  transition  between  predecessor  and  successor. 

PARAM  RANGE 

Real  niunber  value  which  is  the  composite  curve  parameter  value  at  this  join. 


34 


ISO  TC184/SC4/WG1 


ANNEX  D 
(Draft  Proposal) 


October  31,  1988 


N288 


Section  2:  NOMINAL  SHAPE  INFORMATION  MODEL 


Business  Rules 
EXPRESS  Specification 

See  attribute  “tegments"!!!  EXPRESS  for  COMPOSITE. CURVE/GEO-33. 
Entity  Name:  PCURVE 

Entity  Number;  GEO>46 

A curve  defined  in  the  parametric  space  of  a surface, 

y Attributes 

PCURVEJD 

Other  Attributes 

SURFACE  ID  (FK) 

The  surface  on  which  the  curve  lies. 

CURVEJD  (FK) 

A 2D  curve. 

Business  Rules 

EXPRESS  Specification 

ENTITY  pcurve 

SUBTYPE  OF  (curve. on.surf ace) ; 
basis. surface  : surface; 
basis. curve  : curve; 

END.ENTITY; 


Entity  Name!  SURFACE-CURVE 
Entity  Number;  GEO-47 
A bounded  curve  on  a surface. 

Primary  Key  Attributes 

SURFACE.CURVEJD 
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Other  Attributes 

CURVE  ID  (FK) 

The  curve  which  is  the  three  dimension&l  im&ge  of  the  ttirface  curve. 

SURFACE  JD  (FK) 

The  surface  on  which  the  curve  lies. 

MASTER 

Enumeration  selection  for  representation  “preferred”  by  sending  system. 
Business  Rules 


EXPRESS  Specification 

ENTITY  surf ace. curve 

SUBTYPE  OF  (curve. on. lurf ace) ; 
surface. 1 : surface; 

curve.l  : curve; 

pcurve.sl  ; OPTIONAL  peurve; 

master  : OPTIONAL  enumeration. curvel.pcurvel ; 

END.ENTITY; 


Entity  Name;  SURFACE  CURVE-PCURVE 
Entity  Number:  GEO-48 

Captures  information  that  a SURFACE.CURV'E/GEO-47  may  optionally  have  an  associated 
PCURVE/GEO-46.  An  associated  PCURVE/GEO-46  is  the  two  dimension^  parametric  image  of 
the  SURFACE-CURVE/GEO-47. 

Primary  Key  Attributes 
SURFACE  CURVE  JD  (FK) 

Other  Attributes 

PCURVEJD  (FK) 

The  curve  which  is  the  two  dimensional  image  of  the  surface  curve. 

Business  Rules 

EXPRESS  Specification 

See  attribute  “pcurve.sl”  in  EXPRESS  for  SURFACE.CURVE/GEO-47. 
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Entity  Name;  INTERSECTION-CURVE 
Entity  Number;  G£0«49 

Ar.  sr.t?rs?rtion  ctirve  is  defined  by  intersecting  two  surfaces.  The  multiple  representation  permits 
the  receiving  system  to  recompute  the  intersection  curve  if  it  has  the  capability. 

Primary  Key  Attributes 

INTERSECTION -CURVE  JD 

Other  Attributes 

CURVEJD  (FK) 

MASTER-REPRESENTATION 

Enumeration  selection  for  representation  “preferred"  by  sending  system. 
SELFJNTERSECTION 

Three  >'alue  flag  to  indicate  whether  curve  self  intersects: 

TRUE 

Curve  does  self  intersect. 

FALSE 

Curve  does  not  self  intersect. 

UNDEFINED 

Whether  curve  self  intersects  or  not  is  unknown. 

Business  Rules 


EXPRESS  Specification 


ENTITY  intersection.curve 

SUBTYPE  OF  (curve.on.aurtace) ; 


pcurve.Bl 
surface. si 
pcurve_s2 
surface. s2 
basis. curve 
■aster. representation 
self .intersection 
END-ENTITY; 


OPTIONAL  pcurve; 

OPTIONAL  surface; 

OPTIONAL  pcurve; 

OPTIONAL  surface; 
curve : 

OPTIONAL  intersection-enumeration ; 
true. f alee. or.undefined; 
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Entity  Name;  COMPOSITE.CURVE.ON-SURFACE 

Entity  Number;  GEO*50 
An  assembly  of  curves  on  a surface. 

Primary  Key  Attributes 
COMPOSITE-CURVE-ON  SURFACE  JD 

Other  Attributes 

SURFACEJD  (FK) 

CLOSED.CURVE 

Logical  value  which  indicates  whether  the  curve  is  closed  (TRUE)  or  open  (FALSE). 
SELFJNTERSECTION 

Three  value  flag  to  indicate  whether  curve  self  intersects: 

TRUE 

Curve  does  self  intersect. 

FALSE 

Curve  does  not  self  intersect. 

UNDEFINED 

Whether  curve  self  intersects  or  not  is  unknown. 

Business  Rules 


EXPRESS  Specification 


ENTITY  composite.curve.on.eurface 
SUBTYPE  OF  (curve_on_8urlace) ; 


basis. surface 
closed.curve 
segments 
senses 
transitions 
END.ENTITY; 


surface; 

LOGICAL; 

LIST  [!:•]  OF  curve. on. surf ace ; 

ARRAY  [l:f]  OF  LOGICAL; 

ARRAY  [l:f]  OF  curve. transition. code ; 


Entity  Name:  PCURVE.PCURVE JNTERSECTION 

Entity  Number;  GEO*51 

One  of  three  definition  choices  of  the  INTERSECTION. CURVE/GEO-49.  In  this  choice  the  inter- 
section curve  is  defined  with  two  PCURVE/GEO-46. 
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Primary  Key  Attributes 
INTERSECTION. CURVE JD  (FK) 

Other  Attributes 

PCURVE-Sl.PCURVEJD  (FK) 

The  intersection  curve  of  the  two  surfaces  defined  in  the  parametric  space  of  the  first  surface. 
PCURVE.S2.PCURVEJD  (FK) 

The  intersection  curve  of  the  two  surfaces  defined  in  the  parametric  space  of  the  second 
surface. 

Business  Rules 
EXPRESS  Specification 

See  EXPRESS  for  INTERSECTION.CURVE/GEO-49.  This  IDEFIX  entity  represents  one  valid 
set  of  options. 

Entity  Name:  PCURVE^URFACE JNTERSECTION 

Entity  Number;  GEO>52 

One  of  three  definition  choices  of  the  INTERSECTION.CURVE/GEO-49.  In  this  choice  the  inter- 
section curve  is  defined  with  one  PCUR\X/GEO-46  and  one  SURFACE/GEO-7. 

mary  Key  Attributes 
INTERSECTION-CURVEJD  (FK) 

Q t h e r Attributes 

P CURVE  ID  (FK) 

The  intersection  curve  of  the  two  surfaces  defined  in  the  parametric  space  of  the  first  surface. 

SURFACEJD  (FK) 

The  second  surface  of  the  intersection. 

Business  Rules 
EXPRESS  S pecification 

See  EXPF4.ESS  for  INTERSECTION.CURVE/GEO-49.  This  IDEFIX  entity  represents  one  valid 
set  of  options 
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Entity  Name;  SURFACE-SURFACE JNTERSECTION 
Entity  Number;  GEO«53 

One  of  three  definition  choices  of  the  rNTERSECTION.CURVE/GEO-49.  In  this  choice  the  inter- 
section ctirve  is  defined  with  two  SURFACE/GEO-7. 

Primary  Key  Attributes 

INTERSECTION.CURVEJD  (FK) 

Other  Attributes 

SURFACE  Sl.SURFACE  ID  (FK) 

The  first  nirface  of  the  intersection. 

SURFACE. S2. SURFACE  ID  (FK) 

The  second  surface  of  the  intersection. 

Business  Rules 
EXPRESS  Specification 

See  EXPRESS  for  INTERSECTION. CURVE/GEO-49.  This  IDEFlX  entity  represents  one  vaUd 
set  of  options. 

Entity  Name;  ON-SURFACE-SEGMENT 
Entity  Number;  GEO-54 

The  use  of  a CUR\’E-ON.SURFACE/GEO-23  as  a component  curve  of  a 
COMPOSITE.CURVE.ON.SURFACE/GEO-50. 

Primary  Key  Attributes 

COMPOSITE.CURVE.ON.SURFACE.ID  (FK) 

ON  SURFACE-SEGMENT-ID 

O t h c_r_  A 1 1 rj  but  e s 

CURVE-ON-SURFACE-ID  (FK) 

A component  curve. 

SENSE 

Logical  value  which  indicates  whether  the  sense  of  this  component  curve  agrees  (TRUE)  with 
the  composite  curve  or  not  (FALSE). 
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Business  Rules 
EXPRESS  Specification 

See  attribute  “eegmentr  in  EXPRESS  for  COMPOSITE.CURVE.ON^URFACE/GEO-50. 
Entity  Name;  ON.SURFACE-SEGMENT-ORDER 

Entity  Number;  GEO>55 

IDEFIX  defaults  to  unordered  sets.  This  entity  makes  ON^URFACE-SEGMENT/GEO-54  an 
ordered  list. 

Primary  Key  Attributes 
COMPOSITE.CURVE.ON^URFACEJD  (FK) 
PREDECESSOR.ON-SURFACE-SEGMENTJD  (FK) 

SUCCESSOR  ON^URFACE-SEGMENTJD  (FK) 

Other  Attributes 

TRANSITION 

Enumeration  selection  for  the  transition  code  between  predecessor  curve  and  successor  curve. 
This  appLes  to  the  3-D  representations  of  curves,  not  to  pcxirves. 

Business  Rules 
EXPRESS  Specification 

See  attribute  “segments”  in  EXPRESS  for  COMPOSITE.CURVE.ON^URFACE/GEO-SO. 
Entity  Name;  TWO  JD -OFFSET-CURVE 

Entity  Number;  GEO>S6 

This  defines  a simple  plane-offset  curve  by  offsetting  by  DISTANCE  along  the  normal  to  BA- 
SIS .CURVE  in  the  plane  of  BASIS  .CURVE. 

Primary  Key  Attributes 
2D.OFFSET.CURVEJD 

Other  Attributes 

None 
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Business  Rules 

EXPRESS  Specification 

ENTITY  d2_off •®t_curv« 

SUBTYPE  OF  (offBst.curv®) ; 
basis.curv®  : corv®; 
distance  : REAL; 

self. intersect  : true.false.or.nndefined; 
END.ENTITY; 


Entity  Name;  THREE-D.OFFSET.CURVE 
Entity  Number;  GEO-57 

A ciirve  generated  as  an  offset  from  another  curve  in  three  space. 

Primary  Key  Attributes 
3D. OFFSET  CURVE  JD 

Otlier  Attributes 

None 

Busin  ess  Ru  l_es 


EXPRESS  Specification 

ENTITY  d3_of f set.curve 

SUBTYPE  OF  (off set. curve) ; 
basis. curve  : curve; 
distance  : REAL; 

self .intersect  : true.false.or.undef ined; 
ref .direction  : direction; 

END.ENTITY; 


Entity  Name;  ELEMENTARY-SURFACE 
Entity  Number;  GEO-58 

The  class  of  elementary  surfaces.  Namely  plane,  cylinder,  cone,  sphere  and  torus. 
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Primary  Key  Attributes 

ELEMENTAL -SURFACE  JD 

Other  Attributes 

ELEMENTAL.SURFACE.TYPE  (diicriminator) 

AXIS2-PLACEMENTJD  (FK) 

Location  and  orientation  of  the  lurface. 

Busines s Rules 

EXPRESS  Specification 

ENTITY  •lenentary. turf ace 
SUPERTYPE  OF  (plane  XOR 

cylindrical. enrf ace  lOR 
conical. surface  XOR 
spherical. surface  XOR 
toroidal. surf ace) 

SUBTYPE  OF  (surface); 

END.ENTITY; 

Entity  Name:  BEZIER.SURFACE 

Entity  Number;  GEO* 5 9 
A Bezier  surface. 

Primary  Key  Attributes 

BEZIER-SURFACEJD 

Other  Attributes 

U.RATIONAL 

Logical  value  which  indicates  whether  the  surface  is  rational  (TRUE)  or  simple  polynomial 
(FALSE)  in  first  (u)  parametric  direction. 

VJIATIONAL 

Logical  \-alue  which  indicates  whether  the  surface  is  rational  (TRUE)  or  simple  polynomial 
(FALSE)  in  second  (v)  parametric  direction. 
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U. UMFOR.M 

Logical  value  which  indicates  whether  the  knot  set  is  uniform  (TRUE)  or  not  uniform  (FALSE) 
in  “u”. 

V.  UNIFORM 

Logical  value  which  indicates  whether  the  knot  set  is  uniform  (TRUE)  or  not  uniform  (FALSE) 
in  “v”. 

U-DEGREE 

Integer  value  which  is  the  algebraic  degree  of  the  basis  functions  in  “u". 

VJDEGREE 

Integer  value  which  is  the  algebraic  degree  of  the  basis  ftinctions  in  “v”. 

FORM -NUMBER 

Enumeration  selection  used  to  identify  the  partictilar  type  of  surface. 

Business_Rul5S 


EXPRESS  Specification 


ENTITT  bezier.surfaca 

SUBTYPE  OF  (bound«d_aurlaca) : 


u.rational 

LOGICAL; 

▼.rational 

LOGICAL; 

u.uniiorm 

LOGICAL; 

▼.uniform 

LOGICAL; 

u. degree 

INTEGER; 

▼.degree 

INTEGER; 

u.upper 

INTEGER; 

▼.upper 

INTEGER; 

control.points 

ARRAY  [0 
ARRAY  [0 

veights 

OPTIONAL 

form. number 
END.ENTITY; 

OPTIONAL 

u.uppar]  OF 

▼.upper]  OF  cartes ian.point ; 
ARRAY  [0:u. upper]  OF 
ARRAY  [0:v.upper]  OF  REAL; 
bspline.suxf  ace.fom; 


Entity  Name;  B .SPLINE.SURFACE 
Entity  Number;  GEO-60 
A b-spline  surface. 
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Primary  Key  Attributes 

B -SPLINE  -SURFACE  JD 

Other  Attributes 

UJUTIONAL 

Logical  value  which  indicates  whether  the  surface  is  rational  (TRUE)  or  simple  polynomial 
(FALSE)  in  first  (u)  parametric  direction. 

VJUTIONAL 

Logical  value  which  indicates  whether  the  surface  is  rational  (TRUE)  or  simple  polynomial 
(FALSE)  in  second  (v)  parametric  direction. 

U. UNTFORAI 

Logical  value  which  indicates  whether  the  knot  set  is  uniform  (TRUE)  or  not  uniform  (FALSE) 
in  “u”. 

V.  UNIFORM 

Logical  >'alue  which  indicates  whether  the  knot  set  is  uniform  (TRUE)  or  not  uniform  (FALSE) 
in  “v”. 

UJDEGREE 

Integer  value  which  is  the  algebraic  degree  of  the  basis  functions  in  “u”. 

VJDEGREE 

Integer  value  which  is  the  algebraic  degree  of  the  basis  functions  in  “v”. 

FORM  NUMBER 

Enumeration  selection  used  to  identify  the  particular  type  of  stirface. 

Business  Rules 


EXPRESS  Specification 


ENTITY  b.spline. surf ace 

SUBTYPE  OF  (bounded. surface) : 


u.  rational 

v. rational 

u. unif  onn 

v. unifonn 

u. degree 

v. degree 

u.  upper 

v. upper 

control.points 


LOGICAL; 

LOGICAL; 

LOGICAL; 

LOGICAL; 

INTEGER; 

INTEGER; 

INTEGER; 

INTEGER; 

ARRAY  [Oru.upper]  OF 
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Q.multipliciti*! 

u.knots 

▼.nultiplicitivs 

▼.knots 

voights 

form.number 

DERIVE 


ARRAY  [0:v_upp«r]  OF  cartssinn.point ; 
ARRAY  [Irknot.tt]  OF  HTTEGER: 

ARRAY  [Irknot.n]  OF  REAL: 

ARRAY  [l:knot.T]  OF  IIITEGER: 

ARRAY  [l:knot.T]  OF  REAL: 

OPTIONAL  ARRAY  C0:u.npp«r]  OF 

ARRAY  C0:y.«pp«r3  OF  REAL; 
OPTIONAL  bsplin*. surf tc«. form; 


knot.u  : INTEGER  :■  u.d«gr*«  4 u.uppsr  ♦ 2; 
knot.v  : INTEGER  :■  ▼.d«gr««  ♦ ▼.uppsr  ♦ 2; 
END.ENTITY; 


Entity  Name:  SWEPT  .SURFACE 

Entity  Number;  GEO>61 

A surface  that  is  constructed  by  sweeping  a curve  by  another  curve. 

Primary  Key  Attributes 
SWEPT.SURFACEJD 


Other  Attri butes 
CURVEJD  (FK) 

DIRECTION  JD  (FK) 
SWEPT.SURFACE-TTTE  (discriminator) 

Business  Rules 


EXPRESS  Specification 

ENTITY  svept. surface 

SUPERTYPE  OF  (surf acs. of .revolution  lOR 

surface.of .linear.eztrusion) 

SUBTYPE  OF  (surface); 

END.ENTITY; 

Entity  Name:  RECTANGULAR-TRIMMED.SURFACE 

Entity  Number;  G£0>62 

A simple  bounded  surface  in  which  the  boundaries  are  constant  parametric  lines. 
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Primary  Key  Attributes 
RECTANGULAR.TRIMMED  .SURFACE  JD 

Other  Attributes 

SURFACEJD  (FK) 

Surface  to  be  trimmed. 

UMIN 

Real  number  value  of  first  “u”  parametric  value. 
UMAX 

Real  number  value  of  second  “n”  parametric  value. 
VMIN 

Real  number  value  of  first  “v”  parametric  value. 
VMAX 

Real  number  value  of  second  “v"  parametric  value. 
Business  Rules 


EXPRESS  Specification 


ENTITY  rectangular.triaaed.furface 
SUBTYPE  OF  (bounded.iurf ace) ; 
basis. surface  : EXTERNAL  surface; 
unin  : REAL; 

vmin  : REAL: 

Umax  : REAL 

vmax  : REAL 

END. ENTITY: 


Entity  Name;  BOUNDED -SURFACE 
Entity  Number:  GEO*63 

A class  of  surfaces  with  finite  area.  The  area  may  be  finite  naturally  (as  a sphere)  or  finite  due  to 
trimming. 

Primary  Key  Attributes 

BOUNDED. SURFACE -ID 
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Other  Attributes 

BOUND -SURFACE.TYPE  (diicriminator) 

Business  Rules 

EXPRESS  Specification 

ENTITY  bouAd«d_turfac« 

SUPERTTPE  OF  (b.apliM.furfac#  XOR 
baziar.tarf ac«  ZOR 
r act angular. trioaad. turf ac*  ZOR 
curva.boundad.furlaca) 

SUBTYPE  OF  (aorfaca); 

END.ENTITY; 

Entity  Name:  OFFSET.SURFACE 

Entity  Number;  GEO>64 

This  is  a procedtiral  definition  of  a simple  offset  surface  at  a normal  distance  from  the  originating 
stirface. 

Primary  Key  Attributes 
OFFSET.SURFACEJD 

Other  Attri but ej 

SURFACE  ID  (FK) 

The  surface  that  is  to  be  offset. 

DISTANCE 

Real  value  which  is  offset  distance. 

SELFJNTERSECTION 

Three  value  flag  to  indicate  whether  ctirve  self  intersects; 

TRUE 

Curve  does  self  intersect. 

FALSE 

Curve  does  not  self  intersect. 

UNDEFINED 

Whether  curve  self  intersects  or  not  is  unknown. 
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Business  Rules 

EXPRESS  Specification 

ENTITY  off ■•t.furf ac* 

SUBTYPE  OF  (turfaca); 
basis. surf aco  : surfaca; 
distaxica  : REAL; 

self .intarsact  ; trua.f alsa.or.ondaf inad ; 
END.ENTITY; 


Entity  Name;  RECTANGULAR.COMPOSITE-SURFACE 
Entity  Number;  GEO>65 

This  is  a composite  surface  having  a simple  rectangular  topology  of  patches.  Each  patch  (component 
surface)  must  be  a bound  and  topologically  rectangular  and  therefore  be  either  a RECTANGU* 
LAR-COMPOSITE^URFACEJ»ATCH/GEO-79  and/or  B JPLINE^URfACE/GEO-60. 

Each  patch  is  , if  necessary,  reparameterixed  from  0 to  1 and  the  resulting  composite  surface 
has  a simple  cumulative  parameterixation. 

It  is  required  that  there  is  at  least  positional  continuity  betwem  adjacent  surfaces. 

Primary  Key  Attributes 
RECTANGULAR.COMPOSITE-SURFACE  JD 

Other  Attributes 

None 

Business  Rules 


EXPRESS  Specification 


ENTITY  rectangular. composita.surf ace 


SUBTYPE  OF 

(surface) ; 

n.u  : 

INTEGER; 

n.v  ; 

INTEGER; 

surfaces  : 

ARRAY  [l:n.u] 

OF 

ARRAY  [l:n.v] 

OF 

surface; 

u. senses  : 

ARRAY  [l:n.u] 

OF 

ARRAY  [l:n.v] 

OF 

LOGICAL: 

V. senses  : 

ARRAY  [l:n.n] 

OF 
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iRRAT  [l:n.v]  OF  LOGICAL: 

END.ENTITT; 

Entity  Name:  PLANE 

Entity  Number:  GEO-66 
A unbounded  planar  surface. 

Primary  Key  Attributes 

PLANEJD 

Other  Attributes 

None 

Business  Rules 

EXPRESS  Specification 
ENTITY  plane 

SUBTYPE  OF  (elementary.iurf ace) ; 
position  : axi62_placement ; 

END. ENTITY: 

Entity  Name:  CYLINDBJCAL-SURFACE 

Entity  Number:  GEO-67 
An  unbounded  cylindrical  surface. 

Primary  Key  Attributes 
CYLINDRICAL^URFACEJD 

Q.th^r  Attributes 
RADIUS 

Real  %'alue  which  is  the  radius  of  the  cylinder. 
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Business  Rules 

EXPRESS  Specification 

EKTITT  cylindrical. •Qrf«c« 

SUBTYPE  OF  (•lamantary.turlaca) ; 

radius  : REAL; 

position  : azi82.placafflant ; 

END.ENTITY; 

Entity  Name;  CONICAL^URFACE 

Entity  Number;  GEO>68 
An  unbounded  surface  of  a cone. 

Primary  Key  Attributes 
CONICAL-SURFACE  JD 

Other  Attributes 

SEMIANGLE 

Real  value  which  is  the  cone  semi-angle  in  degrees. 

RADIUS 

Real  value  which  is  the  radius  of  the  circular  curve  of  intersection  between  the  cone  and  a 
plane  perpendicular  to  the  axis  of  the  cone  passing  through  the  location  point. 

Business  Rules 


EXPRESS  Specification 

ENTITY  conical.furf aca 

SUBTYPE  OF  (alaaantary.aurlaca) ; 
sami. angle  : REAL; 
radius  : REAL; 
position  : azis2.placaaant ; 
END.ENTITY; 


Entity  Name!  SPHERICAL^URFACE 
Entity  Number;  GEO«69 


A complete  spherical  surface. 
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Primary  Key  Attributes 

SPHERICAL  -SURJACE  JD 

Other  Attributes 

RADIUS 

Business  Rule g 

EXPRESS  Specification 

ENTITY  spharical.furlact 

SUBTYPE  OF  (•lamantary.aurlaca) ; 

radius  : REAL; 

position  : azis2.placam«nt ; 

END. ENTITY; 


Entity  Name;  TOROIDAL.SURFACE 
Entity  Number:  GEO-70 
The  complete  surface  of  a torus. 

Primary  Key  Attributes 
TOROIDAL^URFACEJD 

Other  Attributes 
MAJOR-RADIUS 

Real  value  which  is  the  major  radius  of  the  torus. 
MINOR-RADIUS 

Real  value  which  is  the  minor  radius  of  the  torus. 
Business  Rules 


EXPRESS  Specification 

ENTITY  toroidal. surf aca 

SUBTYPE  OF  (alementary. surface) ; 
major. radius  : REAL: 
minor.radiuE  : REAL; 
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poEition  : azi82.plae«ffl9nt ; 

END.ENTITY; 

Entity  Name;  SURFACE.OF-LINEARJEXTRUSION 
Entity  Number;  GEO-71 

A iimple  swept  surface  or  a generalized  cylinder  obtained  by  sweeping  a curve  in  a given  direction. 

Primary  Key  Attributes 
SURFACE-OFXINEAR-EXTRUSIONJD 

Other  Attributes 

DIRECTION  JD  (FK) 

The  direction  of  extrusion. 

CURVE JD  (FK) 

The  curve  to  be  swept. 

B usln  e^  .Rule  s 


EXPRESS  Specification 

ENTITY  surf ace_ of .linear. •xtruE ion 
SUBTYPE  OF  (swept. surf ace) ; 
axis  : direction; 

extruded. curve  : curve; 
END.ENTITY; 


Entity  Name;  SURFACE.OF JIEVOLUTION 
Entity  Number;  GEO-72 

A surface  obtained  by  rotating  a curve  a complete  revolution  about  an  axis. 

Primary  Key  Attributes 

SURFACE-OFJIEVOLUTIONJD 
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Other  Attributes 

CARTESUN  J>OINT  ID  (FK) 

A point  on  the  axis  of  revolution. 

DIRECTION  JD  (FK) 

The  direction  of  the  axis  of  revolution. 

CURVEJD  (FK) 

The  curve  that  it  revolved  about  the  axis. 
Business  Rules 

EXPRESS  Specification 

ENTITY  aurfaca.of.ravolution 
SUBTYPE  OF  (swept. surface) ; 
axis.point  : point; 
axis  : direction; 

revolved.curve  : curve; 

END. ENTITY; 


Entity  Name;  B SPLINE-SURFACE-KNOT 
Entity  Number;  GEO-73 
A knot  of  a B-spline  stirface. 

Primary  Key  Attributes 

B. SPLINE -SURFACE  JD  (FK) 

B-SPLINE -SURFACE-KNOT  JD 

Other  Attributes 

U-OR-V 

Enumeration  selection  which  indicatei  whether  this  is  for  the  first  (u)  parametric  or  second 

(▼) 

MULTIPLICITY 

Integer  value  of  multiplicity  of  this  knot. 

KNOT-VALUE 

Real  number  value  of  this  knot  which  is  one  of  a set  of  knots  used  to  define  the  B- spline  basis 
function. 
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Btisir.ess  Rules 
EXPRESS  Specification 

Is  the  EXPRESS  for  B^PLINE^URFACE/GEO-60  lee  the  following  attributes: 

• u^ultipbcities 

• nJtnots 

• T_multiplicities 

• vJtnots 

Entity  Name;  BS.SURFACE-KNOT.ORDER 
Entity  Number;  GEO-74 

IDEFIX  defaults  to  usordered  sets.  This  entity  makes  BS-SURFACE-KNOT/GEO-73  a matrix. 

Primary  Key  Attributes 
B -SPLINE-SURFACE-KNOT  JD 
PREDECESSOR  B^PLINE-SURFACE^NOTJD  (FK) 

SUCCESSOR  B.SPLINE-SURFACE.JCNOT_ID  (FK) 

Other  Attributes 

None 

Business  Rules 
EXPRESS  Specification 

In  the  EXPRESS  for  B.SPLINE-SURFACE/GEO-60  see  the  following  attributes: 

• u-multiplicities 

• u knots 

• v_mtiltipbcities 

• vJcnots 

Entity  Name;  BEZIER-SURFACE.CONTROL-POINT 

Entity  Number;  GEO-77 
A control  point  for  a BEZIER.SURFACE/GEO*59. 
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Primary  Key  Attributes 

BEZIER^URFACEJD  (FK) 

BEZIER-SURJACE.CONTROLJ»OINT-ID 

Other  Attributes 
CARTESIAN  J>OINT  (FK) 

WEIGHT 

Real  number  value  of  weight  associated  with  this  control  point. 

B U sin  css.Jlu,Us 

EXPRESS  Specification 

In  the  EXPRESS  for  BEZIER-SURFACE/GEO-59  see  attribute  controLpoints. 

Entity  Name;  BZ.SURFACE.CONTROL  J>OINT.ORDER 

Entity  Number;  GEO-7® 

IDEFlX  defaults  to  xinordered  sets.  This  entity  makes 
BEZIER-SURFACE.CONTROL  J»OINT/GEO-77  a matrix. 

Primary  Key  Attributes 

BEZIER  SURFACE  JD  (FK) 

PREDECESSOR  BEZEER^URFACE-CONTROL-POINTJD  (FK) 

SUCCESSOR  BEZIER-SURFACE.CONTROL-POINTJD  (FK) 

U.OR.V 

Enumeration  selection  of  the  parametric  direction  of  the  predecessor-successor  relationship. 

Other  Attributes 

None 

B usin  es_s_  RuLes 
EXPRESS  Specification 

In  the  EXPRESS  for  BEZIER-SURFACE/GEO-59  see  attribute  controLpoints. 
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Entity  Name;  RECTANGULAE.COMPOSITE^URFACE J»ATCH 
Entity  Number;  GEO-79 

The  use  of  a RECTANGULAR.TRIMMED -SURFACE/GEO-62  by  a 
RECTANGULAR.COMPOSITE^URFACE/GEO-65. 

Primary  Key  Attributes 

RECTANGULAR-COMPOSITE-SURFACEJD  (FK) 

RECTANGULAR-TRIMMED JURFACEJD  (FK) 

Other  .Attributes 

UJENSE 

Logical  value  which  indicates  whether  the  sense  of  “u”  parameteriration  in  composite  agrees 
with  (TRUE)  the  original  surface. 

V SENSE  Logical  value  which  indicates  whether  the  sense  of  "v"  Logical  value  which  indicates 
whether  the  sense  of  “v”  parameterization  in  composite  sigrees  with  (TRUE)  the  original 
surface. 

Business  Rules 
EXPRESS  Specification 

In  the  EXPRESS  for  RECTANGULAR-COMPOSITE^URFACE/GEO-65,  see  the  foUowing  at- 
tributes: 

• surfaces 

• u-senses 

• Tjenses 

Entity  Name;  RC .SURFACE-PATCH. ORDER 
Entity  Number;  GEO-80 

IDEFIX  defaults  to  unordered  sets.  This  entity  makes 
RECTANGULAR.COMPOSITE.JURFACE.PATCH/GEO-79  a matrix. 
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Primary  Key  Attributes 
RECTANGULAK.COMPOSITE^URFACEJD  (FK) 
PREDECESSOR.RECTANGULAR.TRIMMED^URFACEJD  (FK) 
SUCCESSOR.RECTANGULAR.TRIMMED^URFACEJD  (FK) 

U-OR.V 

Enumeration  selection  which  indicates  whether  the  predecessor-successor  relation  is  in  the 
“u”  (U)  or  (V)  direction. 

Other  Attributes 

None 

Business  Rules 

Specification 

In  the  EXPRESS  for  RECTANGULAR.COMPOSITE-SURFACE/GEO-65,  see  the  following  at- 
tributes: 

t surfaces 

• u senses 

• v_senses 

Entity  Name;  BOUNDED^URFACE-BOUNDARY 
Entity  Number;  G£0*81 

The  use  of  a COMPOSITE-CURVE-ON^URFACE/GEO-50  as  part  or  aU  of  the  boundary  of  a 
CURVE_BOUNDED^URFACE/GEO-110. 

Primary  Key  Attributes 
CURVE  BOUNDED. SURFACE JD  (FK) 

COMPOSITE  CURVE-ON^URFACEJD  (FK) 

Other  Attributes 

None 
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Business  Rules 
EXPRESS  Specification 

In  EXPRESS  for  CURVE-BOUNDED^URFACE/GEO*110,  see  attribute  “boxindaries”. 

Entity  Name;  CURVE-BOUNDED^URFACE 

Entity  Number;  GEO-110 

A surface  trimmed  with  COMPOSITE  CURVE  ON.SURFACE/GEO-50  entities.  If  the  outer 
boundary  is  omitted,  the  natural  boundaries  of  the  trimmed  surface  are  assumed. 

Primary  Key  Attributes 

CURVE  BOUNDED  .SURFACE  ID 

Other  Attributes 

SURFACEJD  (FK) 

The  surface  to  be  bound. 

OUTER-PRESENT 

Logical  value  to  indicate  whether  the  outer  boundary  is  expUcitly  present  (TRUE)  or  is 
defaulted  to  the  natural  boimdary  (FALSE). 

Business  Rules 

EXPRESS  Specification 

ENTITY  curve_bound«d_iurface 
SUBTYPE  OF  (boundad.aurfaca) ; 
basis. surface  : surface; 

boundaries  : SET  [1:#]  OF  compos ite.curve.on.eurf ace ; 
outer.present  : LOGICAL; 

END.ENTITY; 
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Entity  Name:  SOLID  MODEL 

Entity  Number;  GEO-82 

A complete  representation  of  product  nominal  shape;  any  point  can  be  classified  as  being  inside, 

outside  or  on  the  boundary  of  a solid. 

Primary  Key  Attributes 

SOLID -MODELJD 

Other  Attributes 

SOLID -MODEL-TYPE  (discriminator) 

Business  Rules 

EXPRESS  Specification 

ENTITY  solid_model 

SUPERTYPE  OF  (boolean_operation  XOR 
csg.primitive  XOR 
csg.Eolid  XOR 
f acetted.brep  XOR 
half.space  XOR 
manif old.solid.brep  XOR 
solid.instance  XOR 
8 wept. area. solid) 

SUBTYPE  OF  (shape.model) ; 

END.ENTITY; 

Entity  Name;  CSG.PRIMITIVE 

Entity  Number;  GEO-84 

A collector  for  aU  CSG  primitives.  A primitive  is  a simple  solid  used  in  the  construction  of  more 

complex  solids  using  regularized  operations. 

Primary  Key  Attributes 

CSG -PRIMITIVE  JD 
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Figure  D-22;  SHAPE  Entity /Eelationthip  Di&gr&m 
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3.4  SOLIDS 

Entity  Name;  SOLID-MODEL 
Entity  Number:  GEO-82 

A complete  representation  of  product  nominal  shape;  any  point  can  be  classified  as  being  inside, 
outside  or  on  the  boundary  of  a solid. 

Primary  Key  Attributes 
SOLID -MODEL  JD 

Other  Attributes 
SOLID  MODEL. TYPE  (discriminator) 

Business  Rules 


EXPRESS  Specification 

ENTITY  Eolid.Bodal 

SUPERTYPE  OF  (bool«an_op«ration  XOR 
cag.primitiv*  XOR 
CEg.aolid  XOR 
facattad.brap  XOR 
half.apaca  XOR 
manifold.iolld.brep  XOR 
solid. instanca  XOR 
evapt.araa. solid) 

SUBTYPE  OF  (shape.Bodel) ; 

END. ENTITY; 

Entity  Name;  CSG -PRIMITIVE 
Entity  Number;  GEO-84 

A collector  for  aU  CSG  primitives.  A primitive  is  a simple  solid  used  in  the  construction  of  more 
complex  solids  using  regularized  operations. 

Primary  Key  Attributes 

CSG_PRI^UTIVEJD 
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Figure  D-23:  SHAPE  Entitj/Relationihip  Ditgram 
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Other  Attributes 
CSG-PRINUTrV'E-T\TE  (discriminator) 

Bus_in«s_RuIe5 


EXPRESS  Specification 

ENTITY  csg.primitiva 

SUPERTTPE  OF  (sphar*  lOR 

primitiT«.Yith_on«.uit  XOR 
primitiTa.with.ajtas) 

SUBTYPE  OF  (solid.modal) ; 

END. ENTITY; 


Entity  Name;  CSG. SOLID 
Entity  Number;  GEO>85 

A solid  made  by  combining  liropler  solids  ruing  regularised  Boolean  operations.  The  allowed 
operations  are  intersection,  union,  and  difference.  A regularixed  operation  is  defined  as  the  closure 
of  the  interior  of  the  result  of  the  Boolean  operation. 

The  CSG-SOLLD  entity  serves  two  functioiu.  First  it  identifies  the  root  Boolean  operation. 
Second  it  is  a means  to  dilTerentiate  intermediate  results  and  significant  results.  The  result  of  the 
Boolean  operation  pointed  to  by  a CSG-SOLID  is  significant  and  should  be  kept,  otherwise,  the 
result  is  only  an  intermediate  result. 

Primary  Key  Attributes 
CSG-SOLID  ID 

Other  Attributes 
BOOLEAN.OPERATIONJD  (FK) 

Boolesin  expression  of  primitives  and  regularired  operators  describing  the  solid. 

FLuii ness  Rules 


EXPRESS  Specification 

ENTITY  csg.Bolid 

SUBTYPE  OF  (solid.Bodel) ; 
tree.expression  : boolean. operation; 
END.ENTITY; 
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Entity  Name:  FACETTED_B^EP 

Entity  Number;  G£0*86 

The  FACETTED  BREP  has  been  introduced  in  order  to  lupport  the  large  number  of  svstems 
that  allow  boundary  t}^e  solid  representations  with  planar  surfaces  only.  Facetted  models  mar  be 
represented  by  MANIFOLD  JOLID_B -REP/GEO-88  but  their  representation  as  a 
FACETTED-B REP/GEO-86  will  be  more  compact. 

Primary  Key  Attributes 

FACETTED.BREPJD 

Qtb  er_  At  t ributej 

SHELLXOGICAL  JTRUCTURE-ID  (FK) 

A closed  shell  defining  the  exterior  boundary  of  the  solid. 

B.U I i ness  Rules 


EXPRESS  Specification 

ENTITY  facetted. brep 

SUBTYPE  OF  (Eolid.model) ; 
outer  ; shell. logical.structure ; 
voids  : SET  [0:f]  OF  ehell. logical. structure : 
END. ENTITY; 


Entity  Name;  HALF.SPACE 
Entity  Number;  GEO-87 

The  half  space  which  is  the  regular  subset  of  the  domain  which  lies  on  one  side  of  an  unbounded 
surface.  The  domain  is  an  orthogonal  box  or  aR  space  (all  space  is  the  default).  See 
BOX-DOMAIN/GEO-109  for  domain  definition.  Which  side  of  the  surface  is  determined  by  the 
surface  normals  and  the  complement  flag  If  the  complement  flag  is  FALSE,  then  the  subset  is  the 
one  the  normals  point  away  from.  If  the  complement  flag  is  TRUE,  then  the  subset  is  the  one  the 
normals  point  into. 

For  a valid  H.-MF  SPACE/GEO-87,  the  surface  must  divide  the  domain  into  exactly  two  subsets. 
Also,  wjthin  the  domain  the  surface  must  be  manifold  and  all  the  surface  normals  must  point  into 
the  same  subset. 


85 


ISO  TC184/SC4/WG1 


ANNEX  D 
(Draft  Proposal) 


October  Cl,  1988 


N288 


Section  2:  NOMINAL  SHAPE  INFORMATION  MODEL 

Primary  Key  Attributes 

HALF  ^PACE-S  OLID  JD 

Other  Attributes 

SURFACEJD (FK) 

Surface  defining  lide  of  half  space. 

COMPLEMENTJLAG 

Logical  value  which  ii  the  complement  flag  defined  above. 

Business  Rules 

EXPRESS  Specification 

ENTITY  half.space 

SUBTYPE  OF  (solid.Bodel) ; 
base.surface  : surface; 
enclosure  : OPTIONAL  box.domain; 

complement.! lag  : LOGICAL; 

END. ENTITY; 

Entity  Name;  MANIFOLD.SOLID .B .REP 

Entity  Number:  GEO-88 

A manifold  solid  is  an  arcwise  connected  closed  finite  volume  and  the  lurface(s)  of  the  solid  is 
arc  wise  connected  orient  able  compact  two- manifold.  There  is  no  restriction  on  the  genus  of  the 
volume,  nor  on  the  number  of  voids  within  the  volume. 

Primary  Key  Attributes 

MANIFOLD -SOLED  _B  JlEP  JD 

Other  Attributes 

CLOSED ^HELL-LOGICAL-STRUCTUREJD  (FK) 

A closed  shell  defining  the  exterior  boundary  of  the  solid. 

Business  Rules 

EXPRESS  Specification 

ENTITY  manifold. solid. br«p 
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SIJBTTPE  OF  (solid_Bod«l) ; 

oat«r  : sh«ll.logicftl_*trQcttir« ; 

voids  : SET  OF  [0:i]  OF  ibcll. logical. ttmetur* ; 

END. ENTITY: 

Entity  Name;  SOLID  JNSTANCE 
Entity  Number;  G£0>89 
A copy  of  another  solid  at  a new  location. 

Primary  Key  Attributes 

SOLID  JKSTANCEJD 

Other  Attributes 
AXIS2J*LACEMENTJD  (FK) 

Location  and  orientation  at  which  the  sobd  instance  takes  place. 
SOLID  MODEL  ID  (FK) 

Solid  Model  which  is  the  object  of  the  solid  instance. 

Business  Rules 


EXPRESS  Specification 

ENTITY  solid.instanca 

SUBTYPE  OF  (Bolid.model) ; 
solid.to.be.copiad  : folid.Bodal; 
location  : azis2.plac«ment ; 

END. ENTITY: 

Entity  Name;  SWEPT JkREA-SOLID 
Entity  Number;  GEO-90 

A collector  for  solids  defined  by  a sweeping  action  on  planar  faces. 

Primary  Key  Attributes 

SWEPT_AREA-SOLIDJD 
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Other  Attributes 

SWEPT-AREA  .SOLID  .TYPE  (discriminator) 

FACEJD  (FK) 

Face  to  be  swept. 

Business  Rules 

EXPRESS  Specification 

ENTITY  Bwept.&rea.solid 

SUPERTYPE  OF  (solid. of .ravolution  XOR 

Bolid.of. linear .•xtrus ion) 
SUBTYPE  OF  (solid.model) ; 

END. ENTITY; 


Entity  Name;  BOOLEAN-OPERATION 
Entity  Number;  GEO- 91 

A regularized  operation  on  two  solids  to  create  a new  solid.  Valid  operations  are  regularized 
union,  regularized  intersection,  regularized  complement,  and  regularized  difference.  For  purposes 
of  Boolean  operations,  a solid  is  a regularized  set  of  points. 

Primary  Key  Attributes 
BOOLEAN.OPERATIONJD 

Other  Attributes 

BOOLEAN . OPERATION. T'iTE  (discriminator) 

Business  Rules 

EXPRESS  Specification 

ENTITY  boolean. operation 
SUPERTYPE  OF  (union  lOR 

intersection  XOR 
difference) 

END. ENTITY: 
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Entity  Name;  UNION 
Entity  Number;  GEO*92 

UNION  on  two  folids  ii  the  regulariration  of  the  »et  of  all  pointi  that  are  in  the  FIRST. OPERAND 
or  the  SECOND -OPERAND  or  both. 

Primary  Key  Attributes 
UNIONJD 

O t her_  At  t ri^  tes 

FIRST.OPERAND. SOLID -MODELJD  (FK) 

SECOND  0PERAND.S0LID310DELJD  (FK) 

Business  Rules 


EXPRESS  Specification 
ENTITT  union 

SUBTYPE  OF  (bool«an_op«ration) ; 
first. operand  : solid. model; 
second. operand  : solid. model; 
END. ENTITY; 


Entity  Name;  INTERSECTION 
Entity  Number;  GEO-03 

INTERSECTION  on  two  solids  is  the  regularization  of  the  set  of  all  points  that  are  in  both  the 
FIRST.OPERAND  and  the  SECOND  .OPERAND. 

Primary  Key  Attributes 
INTERSECTION  JD 

Other  Attributes 

FIRST -OPERAND. SOLID -MODEL  JD  (FK) 

SECOND. OPERAND  SOLID -MODEL  JD  (FK) 
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Business  Rules 

EXPRESS  Specification 

ENTITY  intersection 

SUBTYPE  OF  (boolean. operation) ; 
lirst.operand  : solid.model; 
second. operand  : solid. aodel; 
END.ENTITY; 


Entity  Name;  DIFFERENCE 
Entity  Number;  GEO>94 

DIFFERENCE  on  two  solids  is  the  regularization  of  the  set  of  aD  points  that  are  in  the 
WORK  J>IECE,  but  not  in  the  TO-BE-REMOVED. 

Primary  Key  Attributes 
DIFFERENCE-ID 

Other  Attributes 

WORK  J>IECE. SOLID  J^IOLDEL-ID  (FK) 

TO-BE-REMOVED. SOLID -MODEL-ID  (FK) 

Business  Rules 


EXPRESS  Specification 

ENTITY  difference 

SUBTYPE  OF  (boolean.operation) ; 
vork. piece  : solid.model; 
to. be. removed  : solid.model; 
END.ENTITY; 


Entity  Name;  BREP-SHELL-IOGICAL-STRUCTURE 
Entity  Number;  GEO-96 

The  use  of  a CLOSED  .SHELL/TOP-18  by  a MANIFOLD -SOLID -B -REP/GEO-88  as  a interior 
void. 
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Primary  Key  Attributes 
MANIFOLD -SOLID -BJIEPJD  (FK) 

CLOSED^HELLJD  (FK) 

Other  Attributes 

FLAG 

Logical  value  which  indicates  whether  the  shell  normal  agrees  with  (TRUE) 
opposite  direction  (FALSE)  to  the  manifold  solid  normal. 

B usjnessjlul  es 

EXPRESS  Specification 

ENir'Y  closed_8hell_logical.ttnictur« ; 
closed.shell. element  : closed. shell ; 
flag  : LOGICAL; 

END. ENTITY: 

Entity  Name;  PRIMITIVE-WITH.ONE-AXIS 
Entity  Number:  GEO*97 
A collector  for  axis  sjTnmetrical  CSG  primitives. 

Primary  Key  Attributes 
PRIMITIVE .\\1TH  ONE-AXIS  JD 

Other  Attributes 

PRIMITIVE.\\TTH.ONE-AXIS-TYPE  (discriminator) 

AXISl-PLACEMENT  (FK) 

The  location  of  a point  on  the  axis  and  the  direction  of  the  axis. 

Business  Rules 


EXPRESS  Specification 

ENTITY  primitive. with. one. axis 

SUPERTYPE  OF  (right. circular. cone  lOR 

right.circular. cylinder  lOR 
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torus) 

SUBTTPE  OF  (csg.primitivs) ; 

END.ENTITT; 

Entity  Name;  RIGHT.CIRCULAR.CYLINDER 

Entity  Number;  G£0>98 

A right  circtilar  cylinder  CSG  primitive. 

Primary  Key  Attributes 
RIGHT-CmCULAR-C’iXINDERJD 

Other  Attributes 
RADIUS 

Real  number  value  which  is  the  radius  of  the  cylinder. 
HEIGHT 

Real  number  value  which  is  the  height  of  the  cylinder. 
Business  Rules 


EXPRESS  Specification 

ENTITY  right. circular. cylinder 

SUBTTPE  OF  (primitive. with. one. axis) ; 

radius  : REAL; 

position  : azisl.placement ; 

height  : REAL; 

END. ENTITY; 


Entity  Name;  RIGHT.CIRCULAR.CONE 

Entity  Number;  GEO*99 

A right  circular  cone  CSG  primitive. 

Primary  Key  Attributes 
RIGHT.CIRCULAR.CONEJD 
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Other  Attributes 

SEMI-ANGLE 

Real  number  value  which  ii  one  half  the  angle  of  the  cone  in  degrees. 

RADIUS 

Real  number  value  which  it  the  radius  of  the  cone  at  the  axis  point.  That  is  a non-zero  radius 
means  the  cone  is  truncated. 

HEIGHT 

Real  number  value  which  is  the  distance  the  base  of  the  cone  and  the  point  at  which  the 
radius  is  measured. 

Business  Rules 

EXPRESS  Specification 

ENTITY  right_circular_con« 

SUBTYPE  OF  (primitive.with.one.axia) ; 

aemi.angle  ; REAL; 

radius  : REAL; 

position  ; axisl.placaaent ; 

height  : REAL; 

END.ENTITY; 


Entity  Name:  TORUS 

Entity  Number;  GEO-100 
A torus  CSG  primitive. 

Primary  Key  Attributes 
TORUS  ID 

Other  Attributes 

MAJOR-RADTUS 

Real  number  which  is  the  radius  of  the  directrix. 

MINOR-RADIUS 

Real  number  which  is  the  radius  of  the  generatrix. 
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Business  Rules 

EXPRESS  Specification 

ENTITY  torus 

SUBTYPE  OF  (primitivs.uith.ons.axis) : 
major. radius  : REAL; 
minor.radius  : REAL; 
position  : arisl.placamant ; 

END. ENTITY: 

Entity  Name;  SPHERE 
Entity  Number;  GEO-101 
A sphere  CSG  primitive. 

Primary  Key  Attributes 

SPHERE JD 

Other  Attributes 

RADIUS 

Real  >'alue  which  is  the  radius  of  the  sphere. 
Business  Rules 

EXPRESS  Specification 
ENTITY  sphere 

SUBTYPE  OF  (csg. primitive) ; 
radius  : REAL; 
center  : point; 

END. ENTITY; 


Entity  Name:  PRIMITIVE-WITH-AXES 

Entity  Number;  GEO*102 
A collector  for  non- Axis jmme trie  CSG  primitives. 
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Primary  Key  Attributes 
PEINUTIVE -WITH-AXES  JD 

Other  Attributes 

PRUvIITIV'E.WITH-AXES.TYPE  (discrinuiiator) 
AXIS2J>LACEMENTJD 

Business  Rules 


EXPRESS  Specification 

ENTITY  priniitiv*_with.ax«8 

SUPERTTPE  OF  (right. angular.wadg*  lOR 
block) 

SUBTYPE  OF  (csg.priffiitiv*) ; 

END. ENTITY; 


Entity  Name;  RIGHT-ANGULAR.WEDGE 
Entity  Number;  GEO*104 

A right  angular  wedge  CSG  primitive.  The  wedge  may  be  truncated  or  come  to  an  apex. 

Primary  Key  Attributes 
RIGHT  J^NGULAR.WEDGEJD 

Other  Attributes 
X 

Real  number  value  which  is  the  liie  of  the  wedge  along  the  X axis. 

Y 

Real  number  value  which  is  the  site  of  the  wedge  along  the  Y axis. 

Z 

Real  number  value  which  is  the  size  of  the  wedge  along  the  Z axis. 

LTX 

Real  number  value  which  is  the  distance  in  the  positive  X direction  of  the  smaller  surface  of 
the  wedge 
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Buginess  Rules 


EXPRESS  Specification 

EKTITT  right_angtilar_w*dg« 

SUBTYPE  OF  (priinitiv«.Bith.ax*8) ; 
X : REAL: 

y : REAL: 

z : REAL; 

Itx  : REAL; 

position  : axi62.Plac«ffl«nt ; 

END. ENTITY: 


Entity  Name;  BLOCK 
Entity  Number;  GEO>105 
A rectangular  block  CSG  primitive. 

Primary  Key  Attributes 

BLOCKJD 

Other  Attributes 

X 

Real  number  value  which  is  the  lire  of  the  block  along  the  X axis. 
Y 

Real  number  value  which  is  the  sire  of  the  block  along  the  Y axis 
Z 

Real  number  value  which  is  the  sire  of  the  block  along  the  Z axis. 
Business  Rules 


EXPRESS  Specification 

ENTITY  block 

SUBTYPE  OF  (priaitiva.with.axas) ; 
X ; REAL: 

y : REAL; 

z : REAL: 

position  ; axis2. Placement ; 


N2  8 8 
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END. ENTITY; 

Entity  Name;  SOLID -OF_LINEAR_EXTRUSION 
Entity  Number;  GEO-106 

A SOLID .OF_LINEAR_EXTRL  SION  is  a solid  defined  by  sweeping  a planar  face.  The  direction 
translation  is  -lefined  by  a direction  vector.  The  planar  face  may  have  holes  whjch  will  sweep  into 
holes  in  the  suud. 

Primary  Key  Attributes 
SOLID  OF-LINEAR_EXTRUSIONJD 

Other  Attributes 

DIRECTION  ID  (FK) 

The  direction  in  which  the  face  is  to  be  swept. 

DEPTH 

Real  number  which  is  the  distance  the  face  is  to  be  swept. 

Business  Rul^ 

EXI^ES^  Specification 

ENTITY  solid.of .linear. extrusion 
SUBTYPE  OF  (swept. area. solid) ; 
extruded. face  : face; 

extruded. direction  : direction: 
depth  : REAL; 

END. ENTITY; 


Entity  Name;  SOLID .OF_REVOLUTION 
Entity  Number;  GEO-107 

A SOLID  OF  REVOLUTION  is  a solid  formed  by  revolving  a planar  face  about  an  axis.  The  axis 
must  be  in  the  plane  of  the  face  and  the  axis  must  not  intersect  the  interior  of  the  face.  The  planar 
face  may  have  holes  which  will  sweep  into  holes  in  the  solid. 

Primary  Key  Attributes 
SOLID. OF  JIEVOLUTIONJD 


97 


ISO  TC184/SC4/WG1 


ANNEX  D 
(Draft  Proposal) 


October  31,  1988 


N288 


Section  2:  NOMINAL  SHAPE  INFORMATION  MODEL 

Other  Attributes 

AXISl. PLACEMENT JD  (FK) 

Axis  about  which  swept  will  be  made. 

ANGLE 

Real  number  which  is  angle  through  which  the  sweep  will  be  made.  The  angle  is  in  degrees. 
Business  Rules 


EXPRESS  Specification 

ENTITY  6olid_of .revolution 

SUBTYPE  OF  (swept.araa.solid) ; 
axis  : azisl.placamant ; 

•xtruded.f aca  : face; 

angle  : REAL; 

END. ENTITY: 

Entity  Name;  BOX-DOMAIN 
Entity  Number;  GEO-109 

A BOX  DOMAIN  is  an  orthogonal  box  which  may  be  used  to  limit  the  domain  of  a 
HALF-SPACE/GEO-87. 

Primary  Key  Attributes 
HALF-SPACE-SOLID-ID  (FK) 

Other  Attributes 

X-MIN 

Real  value  which  is  X coordinate  of  most  negative  comer  of  box. 

Y.MIN 

Real  value  which  is  Y coordinate  of  most  negative  comer  of  box. 

Z_NnN 

Real  %-alue  which  is  Z coordinate  of  most  negative  comer  of  box. 

X-MAX 

Real  value  which  is  X coordinate  of  most  positive  comer  of  box. 

Y-MAX 

Real  \'alue  which  is  X coordinate  of  most  positive  comer  of  box. 
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Z-MAX 

Real  value  which  is  X coordinate  of  most  positive  comer  of  box. 
Business_  Rules 

EXPRESS  Specification 

ENTITY  box.domain 

x. min  : REAL: 

y. ir.in  : REAL: 

z. min  : REAL: 
x.max  : REAL: 
y_max  : REAL: 
z.max  : REAL: 

END. ENTITY: 
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2.5  TOPOLOGY 

Entity  Name;  TOPOLOGY 

Entity  Number;  TOP-1 

A collector  for  all  topological  entities 

Primary  Key  Attributes 
TOPOLOGYJD 

Other  Attributes 

None 

Business  Rules 


EXPRESS  Specification 
ENTITY  topology 

SUPERTYPE  OF  (vertex  XOR  edge  XOR  path  XOR  loop  XOR  face  XOR 
subface  XOR  shell  XOR  region)  ; 

END.ENTITY; 

VERTEX 

Entity  Numb^:  TOP-2 
A topological  vertex. 

Primary  Key  Attributes 
VERTEXJD 

Other  Attributes 
None 

Business  Rules 

EXPRESS  Specification 

ENTITY  vertex 

SUBTYPE  OF  (topology): 
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vertex.point  ; OPTIONAL  point; 
END.ENTITY; 


Entity  Name;  EDGE 

Entity  Number;  TOP-3 
A topological  edge. 

Primary  Key  Attributes 

EDGEJD 

Other  Attributes 

EDGE.START. VERTEX  JD  (FK) 
Start  point  (vertex)  of  the  edge. 

EDGEJIND  (FK) 

End  point  (vertex)  of  the  edge. 

Business  Rules 


EXPRESS  Specification 


ENTITY  edge 
SUBTYPE  OF 
edge.start 
edge.end 
edge. curve 
END. ENTITY; 


(topology) ; 

: vertex; 

: vertex; 

: OPTIONAL  curve. logical. structure ; 


Entity  Name;  LOOP 

Entity  Number;  TOP-4 
A collector  for  all  types  of  topological  loops. 

Primary  Key  Attributes 

LOOPJD 


Other  Attributes 
LOOP-T^TE  (discriminator) 
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Business  Rules 


EXPRESS  Specification 

ENTITY  loop 

SUPERTYPE  OF  (v«rt«x_loop  lOR  odge.loop  lOR  poly.loop) 
SUBTYPE  OF  (topology) ; 

END.ENTITY; 


Entity  Name:  FACE 

Entity  Number;  TOP-5 
A topological  face. 

Primary  Key  Attributes 

FACEJD 

Other  Attributes 

None 

Business  Rules 


EXPRESS  Specification 

ENTITY  face 

SUBTYPE  OF  (topology); 

outer.bound  : OPTIONAL  loop.logical. structure ; 
bounds  : set  [1  ; •]  OF  loop.logical.structure ; 

face.surface  : OPTIONAL  surface_logical_stracture ; 
END.ENTITY; 


Entity  Name;  SHELL 
Entity  Number;  TOP-6 

A collector  for  all  types  of  topological  shells 

P r ^ ary  Key  Attributes 
SHELLJD 
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Other  Attributes 
SHELL -TYPE  (discriminator) 

Business  Rules 


EXPRESS  Specification 
ENTITY  shell 

SUPERTTPE  OF  (vertex. shell  lOR  wire.shell  lOR  open. shell  lOR 
closed. shell) 

SUBTYPE  OF  (topology): 

END. ENTITY; 


Entity  Name;  PATH 

Entity  Number:  TOP* 7 

A coUectjon  of  edges  joined  end  to  end. 

Primary  Key  Attributes 
PATHJD 

Other  Attributes 

None 

B us iness  Rules 


EXPRESS  Specification 

ENTITY  path 

SUBTYPE  OF  (topology); 

open.edge.list  : LIST  [l  : f]  OF  UNIQUE  edge.logical.structure ; 

END. ENTITY; 

Entity  Name:  SUBFACE 

Entity  Nurnl^er:  TOP-8 

A SUBFACE  is  a portion  of  the  domain  of  a FACE/TOP-5  or  another  SUBFACE/TOP-8 
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Primary  Key  Attributes 

SUBFACE  ID 

Other  Attributes 

None 


Busine s s Rules 


EXPRESS  Specification 

ENTITY  subface 

SUBTYPE  OF  (topology); 

outer. bound  : loop.logical. structure ; 

bounds  : SET  [l  : •]  OF  loop.logical. structure ; 

trimming  : select.face.or.subface ; 

END. ENTITY: 


Entity  Name;  REGION 
Entity  Number:  TOP-9 

A collection  of  SHELL/TOP-6. 

Primary  Key  Attributes 
REGIONJD 

Other  Attributes 

None 

Business  Rules 

EXPRESS  Specification 

ENTITY  region 

SUBTYPE  OF  (topology); 

outer. region.boundary  : OPTIONAL  shell.logical. structure ; 
region. boundaries  : SET  [1  : •]  OF  shell. logical. structure ; 
END. ENTITY; 


N2  8 8 
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Entity  Name;  VERTEX-LOOP 
Entity  Number;  TOP-10 
A loop  composed  of  a single  vertex. 

Primary  Key  Attributes 
VERTEXXOOP-ID 

Other  Attributes 

VERTEXJD  (FK) 

The  unique  vertex  which  composes  the  entire  loop. 
Business  Rules 


EXPRESS  Specification 

ENTITY  vertex.loop 
SUBTYPE  OF  (loop); 
loop.vertex  : UNIQUE  vartax; 
END.ENTITY; 


Entity  Name;  POLY-LOOP 
Entity  Number;  TOP-11 

A ordered  co-planar  collection  of  points  forming  the  vertices  of  a loop.  The  loop  is  composed  of 
straight  line  segments  joining  point  in  the  collection  to  the  succeeding  point  in  the  collection.  The 
closing  segment  is  from  the  last  to  the  first  point  in  the  collection.  The  direction  of  the  loop  is  the 
direction  of  the  line  segments. 

Primary  Key  Attributes 
POLY  LOOPJD 

Other  Attributes 

None 
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Business  Rules 

EXPRESS  Specification 

ENTITT  poly. loop 
SUBTYPE  OF  (loop): 

polygon  : LIST  [3  : #]  OF  UNIQUE  point; 

END. ENTITY; 

Entity  Name;  EDGE  J.OOP 
Entity  Number;  TOP-12 

A topological  loop  represented  by  an  ordered  collection  of  (edge  + logical)  pain  such  that  adjacent 
edges  in  the  loop  are  adjacent  in  the  collection.  The  vertices  of  the  loop  may  be  determined 
by  examining  the  edge  data.  The  logical  indicator  is  used  to  identify  whether  the  positive  edge 
direction  agrees  with  (TRUE)  or  is  opposed  to  (FALSE)  the  positive  direction  of  the  loop. 

Primary  Key  Attributes 

EDGE-LOOP  JD 

Other  Attributes 

None 

Business  Rules 

EXPRESS  Specification 

ENTITY  adge.loop 
SUBTYPE  OF  (loop): 

loop.adges  : LIST  [1  : f]  OF  UNIQUE  adga. logical. atroctura : 

END. ENTITT; 


Entity  Name;  LOCATED.VERTEX 
Entity  Number;  TOP-13 

The  use  of  a POINT/GEO-2  to  locate  a VERTEX/TOP-2  in  a coordinate  space. 

Primary  Key  Attributes 

VERTEX -m  (FK) 
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Other  Attributes 

POINT  JD  (FK) 

Location  of  the  vertex 

Business  Rules 
EXPRESS  Specification 

See  located.vertex  attribute  of  EXPRESS  for  VXRTEX/TOP-2. 

Entity  Name;  POLY-POINT 

Entity  Number:  TOP«14 

The  use  of  a POINT/GEO-2  in  a POLY-LOOP/TOP-11. 

P rimary  Key  Attributes 
POLY -LOOP  JD  (FK) 

POLNTJD  (FK) 

Other  Attributes 

None 

Business  Rules 
EXPRESS  Specification 

See  polygon  attribute  of  EXPRESS  for  POLY  J.OOP/TOP-11. 

Entity  Name;  CURVE J.OGICAL.STRUCTURE 

Entity  Number;  TO  P-1 5 

The  use  of  a CURVE/GEO-6  as  the  underlying  geometry  of  a EDGE/TOP-3. 

Primary  Key  Attributes 
EDGEJD  (FK) 
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Other  Attributes 

CURVE  ID  (FK) 

The  underlying  geometry  of  the  edge. 

FLAG 

Logical  value  which  indicates  whether  the  ctirve  direction  agrees  with  (TRUE)  or  is  in  the 
opposite  direction  (FALSE)  to  the  edge  direction. 

Business  Rules 


EXPRESS  Specification 

ENTITY  curve.logical.itructur® : 
curve.element  : curve; 
flag  : LOGICAL: 

END. ENTITY; 

Entity  Name:  LOOP_EDGE_LOGIC AL^TRUCTURE 

Entity  Number;  TOP»16 

The  use  of  an  EDGE/TOP-3  in  a EDGE-LOOP/TOP-12. 

Primary  Key  Attributes 
EDGE-LOOP  JD  (FK) 

EDGEJD  (FK) 

FLAG 

Logical  value  which  indicates  whether  the  edge  direction  agrees  with  (TRUE)  or  is  in  the 
opposite  direction  (FALSE)  to  the  loop  direction. 

O th er  A tt rib utes 
None 

Business  Rules 
EXPRESS  Specification 

ENTITY  loop. edge. logical.structure ; 
edge. element  : edge; 
flag  ; LOGICAL: 
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EN2_EJ:TITY; 


Entity  Name:  PATH _EDGE_LOGICAL .STRUCTURE 

Entity  Number;  TOP-17 

The  use  of  an  EDGE/TOP-3  in  a PATH/TOP-7. 

Primary  Key  Attributes 

PATHJD  (FK) 

EDGEJD  (FK) 

Other  Attributes 
FLAG 

Logical  value  which  indicates  whether  the  edge  direction  agrees  with  (TRUE)  or  is  in  the 
opposite  direction  (FALSE)  to  the  path  direction. 

Business  Rules 


EXPRESS  Specification 

Use  edge Jogical.structure  defined  in  EXPRESS  for 
L00P-EDGE_L0GICAL-STRUCTURE/T0P-16. 

Entity  Name:  CLOSED.SHELL 

Entity  Number;  TOP-18 

A collection  of  faces  joined  side  to  side  to  create  a boundary  which  divides  space  into  two  regions, 
one  finite  and  the  other  infinite  The  topological  normal  of  the  ihell  is  directed  from  the  finite  to 
the  infijiite  region. 

Primary  Key  Attributes 
CLOSED.SHELLJD  (FK) 

Other  Attributes 

None 
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Business  Rules 

EXPRESS  Specification 

ENTITT  closed. Bh«ll 
SUBTYPE  OF  (8h«ll): 

cshell. boundary  : SET  [1  : f ] OF  f ac«_logical_f tructura ; 
END.ENTITY; 


Entity  Name;  OPEN-SHELL 
Entity  Number;  TOP-19 

A collection  of  faces  joined  aide  to  aide  to  create  an  arcwiae  connected  manifold  oriented  finite 
topological  surfaces  that  is  mappable  to  a plane. 

Primary  Key  Attributes 
OPEN.SHELL-ID 

Oth c r Attributes 

None 

Business  Rules 


EXPRESS  Specification 

ENTITY  open. shell 
SUBTYPE  OF  (shell): 

shell. boundary  ; SET  [1  : • ] OF  face. logical. structure ; 
END.ENTITY; 


Entity  Name:  VERTEX-SHELL 

Entity  Number:  TOP-20 

A shell  consisting  of  a single  VERTEXXOOP/TOP-10. 

Primary  Key  Attributes 
VERTEX  SHELL JD 
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Other  Attributes 
VERTEXXOOPJD  (FK) 

Business  Rules 

EXPRESS  Specification 

ENTITY  vertex.shell 
SUBTYPE  OF  (shell); 

vertex. shell.boundsry  ; UNIQUE  vertex. loop; 

END. ENTITY; 

Entity  Name;  WIRE-SHELL 
Entity  Number;  TOP-21 

A shell  of  dimensionality  1.  It  is  represented  by  a connect  graph,  specihcally  by  the  set  of  loops 
forming  the  graph. 

Primary  Key  Attributes 
WIRE  SHELL  JD 

Other  Attributes 

None 

Business  Rules 

EXPRESS  Specification 

ENTITY  Hire. shell 
SUBTYPE  OF  (shell) ; 

wire. shell. boundary  : SET  [1  : t]  OF  edge.loop; 

END. ENTITY; 


Entity  Name:  CLOSED-SHELL-TACE-LOGICAL-STRUCTURE 

Entity  Number;  TO  P-2  2 

The  use  of  a FACE/TOP-5  as  a component  of  a CLOSED. SHELL/TOP-18. 


120 


ISO  TC184/SC4/WG1 


ANNEX  D 

(Draft  Proposal) 


October  31,  1988 


N2S8 


Section  2:  NOMINAL  SHAPE  INFORMATION  MODEL 


Primary  Key  Attributes 
CLOSED.SHELLJD  (FK) 

FACEJD  (FK) 

Other  Attributes 

FLAG 

Logical  value  which  indicates  whether  the  face  direction  agrees  with  (TRUE)  or  is  in  the 
opposite  direction  (FALSE)  to  the  shell  direction. 

Bus  i.n  e s s . R u les 

EXPRESS  Specification 

ENTITY  face. logical. structure ; 
lace. element  : face; 
flag  : LOGICAL: 

END. ENTITY; 

Entity  Name:  OPEN-SHELL-FACE-LOGICAL^TRUCTURE 

Entity  Number;  TOP*23 

The  use  of  a FACE/TOP-5  as  a component  of  an  OPEN-SHELL/TOP-19. 

Primary  Key  Attributes 
OPEN.SHELL.lD  (FK) 

FACEJD  (FK) 

Other  Attributes 

FLAG 

Logical  value  which  indicates  whether  the  face  direction  agrees  with  (TRUE)  or  is  in  the 
opposite  direction  (FALSE)  to  the  shell  direction. 

Business  Rules 

EXPRESS  Specification 

See  entity  face  Jogical structure  in  EXPRESS  for 
CLOSED-SHELL  JACE_LOGICAL-STRUCTURE/TOP-22. 
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Entity  Name:  SURFACE-LOGICAL-STRUCTURE 

Entity  Number;  TOP-24 

The  use  of  a SURFACE/GEO-7  as  the  geometry  of  a FACE/TOP-5. 

Primary  Key  Attributes 
FACEJD  (FK) 

Q t her  Attri butes 

SURFACE-ID  (FK)  Geometric  surface  underlying  face. 

FLAG 

Logical  value  which  indicates  whether  the  itirface  normal  agrees  with  (TRUE)  or  it  in  the 
opposite  direction  (FALSE)  to  the  face  normal. 

Business  Rules 

EXPRESS  Specification 

ENTITY  surf ace_logical_itnictur« ; 
surf ace. element  : surface; 
flag  : LOGICAL: 

END. ENTITY; 

Entity  Name:  LOOP-LOGICAL-STRUCTURE 

Entity  Number;  TOP-25 

The  use  of  a LOOP/TOP-4  as  a portion  of  or  all  of  the  boundary  of  a FACE/TOP-5. 

Primary  Key  Attributes 

FACEJD  (FK) 

LOOPJD  (FK) 

Other  Attributes 

FLAC- 

Logica!  %'aJ’je  which  indicates  whether  the  loop  direction  agrees  with  (TRUE)  or  is  in  the 
opposite  direction  (FALSE)  to  the  face  direction. 
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OUTER-BOUND 

Three  value  flag  to  indicate  whether  this  loop  is  an  outer  bound. 
TRUE 

Loop  is  outer  bound. 

FALSE 

Loop  is  not  outer  bound. 

UNDEFINED 

Whether  loop  is  outer  bound  or  not  is  unknown. 

Business  Rules 


EXPRESS  Specification 

ENTITY  loop.logical.etructure; 
loop.element  : loop; 
flag  : LOGICAL: 

END.ENTITY; 

For  EXPRESS  of  OUTER.BOUND  attribute  see  “outer.bound”  attribute  in  EXPRESS  for 
FACE/TOP-5. 

Entity  Name;  WIRE.SHELL  J.OOP-LOGICAL.STRUCTURE 
Entity  Number;  TOP*26 

The  use  of  a LOOP/TOP-4  a a component  in  a ^^TRE-SHELL/T0P-21 . 

Primary  Key  Attributes 

WIRE.SHELLJD  (FK) 

EDGE  LOOPJD  (FK) 

Other  Attributes 

FLAG 

Logical  value  which  indicates  whether  the  loop  direction  agrees  with  (TRUE)  or  is  in  the 
opposite  direction  (FALSE)  to  the  used  direction. 

Business  Rules 
EXPRESS  Specification 

See  ENTITY  loopJogical-structure  in  EXPRESS  for  LOOP  J-OGICAL.STRUCTURE/TOP-25 
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Entity  Name;  SUBFACE-ON_FACE 

Entity  Number;  TOP-27 
A SUBFACE/TOP-8  trimming  a FACE/TOP-5. 

Primary  Key  Attributes 
SUBFACEJD (FK) 

Q t h e r Att ri bu t es 
FACEJD  (FK) 

Business  Rules 
EXPRESS  Specification 

Sec  EXPRESS  entity  aubfacc  in  EXPRESS  for  SUBFACE/TOP-8. 

Entity  Name;  RECURSIVE^UBFACE 

Entity  Number;  TOP-28 

A SUBFACE/TOP-8  trimming  another  SUBFACE/TOP-8 

Primary  Key  Attributes 
SUBFACEJD  (FK) 

Other  Attributes 

TRIMMIMG. SUBFACEJD  (FK) 

Business  Rules 
EXPRESS  Specification 

See  EXPRESS  entity  lubfacc  in  EXPRESS  for  SUBFACE/TOP-8. 

Entity  Name:  SUBFACEXOOP JLOGICAL-STRUCTURE 

Entity  Number;  TOP-29 

The  use  of  a LOOP  ''TOP-4  as  a portion  of  or  all  of  the  boundary  of  a SUBFACE/TOP-8. 
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Primary  Key  Attributes 
SUBFACEJD  (FK) 

LOOPJD  (FK) 

Other  Attributes 

FLAG  Logical  value  which  indicates  whether  the  loop  direction  agrees  with  (TRLT)  or  is  in  the 
opposite  direction  (FALSE)  to  the  subface  direction. 

0UTERJ30UND  Three  value  flag  to  indicate  whether  tlus  loop  is  an  outer  bound.  TRUE  -loop  is 
outer  bound.  FALSE  -loop  is  not  outer  bound.  UNDEFINED  -Whether  loop  is  outer  bound 
or  not  is  unknown. 

Business  Rules 
EXPRESS  Specification 

See  ENTITY  loop  Jogicaljtructure  in  EXPRESS  for  LOOPXOGICAL^TRUCTURE/TOP-25. 
Entity  Name;  REGION-SHELLXOGICAL-STRUCTURE 

Entity  Number;  TOP-30 

The  use  of  a SHELL/TOP-6  as  a component  of  a REGION/TOP-9. 

Primary  Key  Attributes 
REGIONJD  (FK) 

SHELLED  (FK) 

FLAG 

Logical  value  which  indicates  whether  the  shell  direction  agrees  with  (TRUE)  or  is  in  the 
opposite  direction  (FALSE)  to  the  region’s  use  of  the  shell. 

Qt  her  At  tributes 

OUTERJIEGIONXOUNDARY 

Three  value  flag  to  indicate  whether  this  shellis  an  outer  bound. 

TRUE 

Shell  is  outer  bound. 

FALSE 

Shell  is  not  outer  bound. 

UNDEFINED 

W’hether  shell  is  outer  bound  or  not  is  unknown. 


125 


ISO  TC184/SC4/WG1 


ANNEX  D 
(Drcift  Proposal) 


October  Cl,  1988 


N288 


Section  2:  NOMINAL  SHAPE  INFORMATION  MODEL 


Business  Rules 

EXPRESS  Specification 

ENTITY  shell.logical.Btructura ; 
8hell_el«inent  : shell; 
flag  ; LOGICAL; 

END.ENTITY; 
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TOPOLOGY/TOP-1 


Figure  D-33:  SHAPE  Entity/Rel&tionshJp  Di&grim 
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LOOfTOP-4 


Figure  D-34;  SHAPE  Entity/Relationship  Diagram 
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SHELUTO»-4 


SL’RFACE 


LOOF 


VnU  SHELL  LOOF 
LOGICAL  SmuCTLTltTOP-H 


1 

FLaC 

OOTtH.tOUHl) 

FLAG 

Figure  D-35:  SHAPE  Entity/Relitionship  Diagram 
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FACETOP-5 


T 
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*uirACtrrop-i 


subface  on  face 
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Figure  D-36;  SHAPE  Entity /Relationship  Diagram 
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REGlONTOP-9 


SHELLn‘OP-6 

£>n'TTY  O 


REGION  SHELL 

LCX3ICAL  STRUCTURLTOP-30 


FL>0 


OUTEH_R£GION_BOUNDAHY 


Figure  D-37;  SHAPE  Entity/ReUtionship  Diagram 
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Number 

NAME 

GEO-1 

GEOMETRY 

GEO-2 

POINT 

GEO-3 

VECTOR 

GEO-4 

AXIS -PLACEMENT 

GEO-5 

TRANSFORMATION  JvlATRIX 

GEO-6 

CURVE 

GEO-7 

SURFACE 

GEO-8 

CARTESIAN -POINT 

GEO-10 

CARTESIAN.TWO-POINT 

GEO-11 

CARTESIAN.THREE-POINT 

GEO-12 

POINT. ON -CURVE 

GEO-13 

POINT.ON.SURFACE 

GEO-14 

DIRECTION 

GEO-15 

TWO-SPACEJDIRECTION 

GEO-16 

THREE-SPACEJDIRECTION 

GEO-17 

VECTOR-WITH  JvlAGNITUDE 

GEO-18 

AXIS1J>LACEMENT 

GEO-19 

AXIS2 -PLACEMENT 

GEO-20 

LINE 

GEO-21 

CONIC 

GEO-22 

BOUNDED  CURVE 

GEO-23 

CURVE.ON.SURFACE 

GEO-24 

OFF-SET 

GEO-25 

CIRCLE 

GEO-26 

ELLIPSE 

GEO-27 

HYPERBOLA 

GEO-28 

PARABOLA 

GEO-29 

LINE.SEGMENT 

GEO-30 

BEZIER.CURVE 

GEO-31 

B -SPLINE -CURVE 

GEO-32 

TRIMMED. CURVE 

GEO-33 

COMPOSITE.CURVE 

GEO-34 

CONTROL -POINT-BEZIER 

GEO-35 

CONTROL  _POINT-ORDER3EZIER 

GEO-36 

KNOT 

GEO-37 

CONTROL  POINT 

GEO-38 

CONTROL-POINT.ORDER 

GEO-39 

POINT.POINT.TRLMMED. CURVE 

GEO-40 

POINT -PARAM.TRIMMED-CURVE 

GEO-41 

PARAM-POENT-TRIMMED-CURVE 

Table  1:  Entity  Pool  - Numeric  Order 
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Number  NAME 

GEO-42  PARAM  PARAM.TRIMMED  CURVE 

GEO-43  KNOT.ORDER 

GEO-44  SEGMENT 

GEO-45  SEGMENT.ORDER 

GEO-46  PCURVE 

GEO-47  SURFACE.CURVE 

GEO^S  SURFACE.CURVE_PCURVE 

GEO-49  INTERSECTION  CURVE 

GEO-50  COMPOSITE.CURVE-ON-SURFACE 

GEO-51  PCURVE  JCURVE  INTERSECTION 

GEO-52  PCURVE^URFACEJNTERSECTION 

GEO-53  SURFACE  .SURFACE  INTERSECTION 

GEO-54  ON.SURFACE^EGMENT 

GEO-55  ON^URFACEJEGMENT-ORDER 

GEO-56  TWOJD.OFFSET.CURVE 

GEO-57  THREEJD.OFFSET.CURVE 

GEO-58  ELEMENTARY^URFACE 

GEO-59  BEZIER^URFACE 

GEO-60  B . SPLINE  .SURFACE 

GEO-61  SWEPT^URFACE 

GEO-62  RECTANGULAR.TRIMMEDFURFACE 

GEO-63  BOUNDED^URFACE 

GEO-64  OFFSETFURFACE 

GEO-65  RECTANGULAR.COMPOSITEFURFACE 

GEO-66  PLANE 

GEO-67  CYLINDRICAL.SURFACE 

GEO-68  CONICAL-SURFACE 

GEO-69  SPHERJCAL.SURFACE 

GEO-70  TORODDAL-SURFACE 

GEO-71  SURFACE-OFJLINEAR  EXTRUSION 

GEO-72  SURFACE.OF.REVOLUTION 

GEO-73  BFPLINEFURFACE_KNOT 

GEO-74  BSFURFACEJCNOT.ORDER 

GEO-77  BEZIER.SURFACE.CONTROLFOINT 

GEO-78  BZFURFACE.CONTROL-POINT-ORDER 

GEO-79  RECTANGULAR. COMPOSITE-SURFACEFATCH 

GEO-80  RC.SURFACEFATCH.ORDER 

GEO-81  BOUNDEDFURFACE-BOUNDARY 

GEO-82  SOLID-MODEL 

GEO-84  CSGFRIMITIVE 


Table  1:  Entity  Pool  - Numeric  Order 
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Number 

NAME 

GEO-85 

CSG. SOLID 

GEO-86 

FACETTED3JIEP 

GEO-87 

HALF^PACE 

GEO-88 

MANIFOLD  J OLID -B -REP 

GEO-89 

SOLID  INSTANCE 

GEO-90 

SWEPTJIREA-SOLID 

GEO-91 

BOOLEAN.OPERATION 

GEO-92 

UNION 

GEO-93 

INTERSECTION 

GEO-94 

DIFFERENCE 

GEO-96 

BREP^HELL-LOGICAL^TRUCTURE 

GEO-97 

PRIMITIVE. WITH  ONE-AXIS 

GEO-98 

RIGHT.CmCULAR.CYLINDER 

GEO-99 

RJGHT.CmCULAR.CONE 

GEO-100 

TORUS 

GEO-101 

SPHERE 

GEO-102 

P RTMITIVE -WITH  JUCES 

GEO-104 

RIGHT-ANGULAR.WEDGE 

GEO-105 

BLOCK 

GEO-106 

SOLID-OFJ-INEAR-EXTRUSION 

GEO-107 

SOLID  .OF  JIEVOLUTION 

GEO-108 

BOX.DOMAIN 

TOP-1 

TOPOLOGY 

TOP-2 

VERTEX 

TOP-3 

EDGE 

TOP-4 

LOOP 

TOP-5 

FACE 

TOP-6 

SHELL 

TOP-7 

PATH 

TOP-8 

SUBFACE 

TOP-9 

REGION 

TOP-10 

VERTEXXOOP 

TOP-11 

POLYXOOP 

TOP-12 

EDGE.LOOP 

TOP-13 

LOCATED. VERTEX 

TOP-14 

POLY-POENT 

TOP-15 

CURVEXOGICAL-STRUCTURE 

TOP-16 

LOOPXDGEXOGICAL-STRUCTURE 

TOP-17 

PATHXDGEXOGICALXTRUCTURE 

TOP-18 

CLOSED-SHELL 

Table  1:  Entity  Pool  - Numeric  Order 
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Number 

TOP-19 

TOP-20 

TOP-21 

TOP-22 

TOP-23 

TOP-24 

TOP-25 

TOP-26 

TOP-27 

TOP-28 

TOP-29 

TOP-30 


2:  NOMINAL  SHAPE  INFORMATION  MODEL 


HAML 


OPENJHELL 
VERTEX -SHELL 
WERE -SHELL 

CLOSED-SHELLJACEXOGICAL-STRUCTURE 

OPEN-SHELL.FACE.LOGICAL.STRUCTURE 

SURFACEXOGICAL.STRUCTURE 

LOOP. LOGICAL -STRUCTURE 

>VTRE.SHELLXOOPXOGICAL.STRUCTURE 

SUBFACE  ON_FACE 

RECURSIVE.SUBFACE 

SUBFACEXOOPXOGICAL -STRUCTURE 

REGION.SHELLXOGICAL.STRUCTURE 
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3 SHAPE  VARIATION  TOLERANCES 

3.1  Abstract 

Dimensions  on  an  engineering  drawing  define  the  theoretically  exact  shape  of  a three-dimensional 
object.  Tolerances  on  those  dimensions  define  the  allowable  deviation  of  the  dimension  from  the 
nomineil  value  as  measured  on  the  manufactured  object.  ANSI  Y14.5M  1982  and  ISO  1660,1101 
specify  the  standard  representation  for  dimensions  and  tolerances  on  engineering  drawings.  The 
reference  model  captures  the  semantic  content  of  the  dimensions  and  tolerances  as  specified  in  those 
standards. 

3.2  Purpose  & Scope 

3.2.1  Purpose 

The  most  important  task  in  a manufacturing  enterprise  is  providing  sufficient  information  to  pro- 
duction to  allow  for  planning,  manufacturing,  and  inspection  of  a product.  This  information  is 
referred  to  as  product  definition  data.  Part  of  the  product  definition  data  is  the  representation  of 
the  desired  shape  of  the  product.  Another,  as  equally  important,  part  of  this  data  is  information 
concerning  how  accurately  the  manufactured  object  must  correlate  to  the  shape  defined  within  the 
product  definition.  These  Limits  on  acceptable  deviation  are  referred  to  as  tolerances.  To  the  design 
engineer,  tolerances  provide  a tool  for  controlling  critical  aspects  of  the  products  shape.  The  process 
planner  must  make  manufacturing  decisions  based  on  tolerances  because  of  the  varying  precision  of 
machine  tools.  Most  importantly,  tolerances  give  Quality  Assurance  criteria  with  which  to  accept 
or  reject  a product. 

Product  definition  data  is  currently  conveyed  on  engineering  drawings.  The  product’s  shape  is 
represented  pictorially  with  graphics  amd  aimotated  dimensions  which  define  the  theoretically  exact 
shape  of  the  product.  Specific  tolerances  are  annotated  to  the  dimensions  and  defaults  are  placed 
elsewhere  on  the  drawing,  typically  in  the  title  block.  As  advanced  manufacturing  systems  make 
more  use  of  digitaJ  product  models,  the  shape  and  the  tolerances  must  be  represented  completely 
and  unambiguously  (this  is  not  to  imply  that  engineering  drawings  are  unambiguous,  however.)  As 
the  communication  of  the  product  definition  data  migrates  from  engineering  drawings  to  digital 
product  models,  it  is  important  that  the  meaning  of  the  dimensions  and  tolerances  as  found  on 
engineering  drawings  be  preserved. 

The  reference  model  contained  in  this  document  attempts  to  identify,  define  and  record  that 
meaning.  It  is  assumed  that  the  readers  of  this  document  have  not  only  a working  knowledge  of  the 
IDEFIX  and  Express  modelling  languages,  but  also  a very  thorough  knowledge  of  dimensioning  and 
tolerancing  practices  as  described  in  the  ANSI  and  ISO  standards.  This  document  is  not  a lesson 
in  dimensioning  fmd  tolerancmg,  but  captures  the  information  content  of  the  standard  practices 
and  concepts. 

3.2.2  Scope  and  Viewpoint 

This  document  provides  the  definition  of  the  functional  content  for  dimensioning  and  tolerancing 
practices  as  specified  by  ANSI  Y14.5M-1986  and  ISO  1101  and  1660.  These  specifications  are 
considered  to  be  functionally  identical  for  the  purposes  of  this  effort. 
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This  information  model  is  intended  to  completely  define  all  tolerance  information  specified  by 
ANSI  Y14.5M-1982  and  the  corresponding  ISO  specifications.  Any  deficiencies  should  be  com- 
mented on  in  writing. 

The  primary  viewpoint  of  the  reference  model  will  be  on  the  application  of  the  tolerances 
specified  in  the  above  standairds  to  three  dimensional,  mechemical  parts. 

The  information  model  contains  the  functional  tolerancing  data  set  as  it  pertains  to  a single  fin- 
ished part  model.  Reference  to  tolerances  as  they  affect  various  stages  of  production  or  preliminary 
forms  of  the  part  (such  as  casted  design)  are  not  accomodated  in  this  model  except  by  reference  to 
a sepau-ate  Product  Model. 

The  tolerances  described  in  the  model  reference  Product  Model  Features  as  described  by  the 
Mechanical  Products,  Form  Features  and  Solids  Committee.  These  include  reference  to  both  explicit 
and  implicit  form  features,  topologies  and  geometries. 

Excluded  from  the  scope  are: 

• Computing  tolerances 

• Process  tolerances 

• Pictorial  representations  of  tolerances 

• Dimensioning  practices  (i.e.  what  constitutes  good  dimensioning  practice) 

• Non-mechanical  part  tolerances  (e  g.  electrical  component  values) 

• Surface  finish/surface  roughness  specifications 

• Efficiencies  regarding  computer  memory  requirements  or  processing  methodologies 

3.3  Fundamental  Concepts  and  Assumptions 

Product  models  are  assumed  to  be  complete,  unambiguous,  three-dimensional  definitions  of  the 
shape  of  the  desired  object,  typically  represented  by  a Boundary  Representation  (BREP)  Solids 
model  or  an  equivaJent  boimded,  surfaced.  Wireframe  Model.  The  general  requirement  is  the 
capability  to  reference  shape  defining  elements  of  the  surface  of  modelled  product.  The  terms 
Area,  Seam  and  Corner,  as  defined  in  the  PDES  Integration  Model,  are  used  within  this  model 
to  refer  to  the  appropriate  shape  element  (and  correspond  roughly  to  the  BREP  notions  of  Face, 
Edge  and  Vertex.) 

Geometric  elements  always  underlie  the  Topologic  elements  Face,  Edge  and  Vertex.  (This 
assumption  is  probably  moot  in  light  of  the  work  of  the  Integration  Committee.) 

Product  Models  contain  exact  definitions  of  nominal  product  geometry,  i.e.  the  model  is  con- 
sidered BASIC. 

The  value  of  the  dimension  is  implicit  in  model  geometry  or  is  an  explicit  parameter  of  an 
implicit  feature.  Each  Tolerance  specified  within  a model  implies  ein  underlying  dimension. 

Graphical  display  of  tolerance  information  will  conform  to  ANSI  Y14.5M  1982,  specifically  the 
Feature  Control  Frame. 
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The  tolerances  described  in  this  information  model  include  both  Coordinate  Tolerances  and 
Geometric  Tolerances.  Both  type  of  tolerances  are  described  as  they  pertain  to  common  tolerancing 
practices  which  are  used  to  define  the  form,  fit  and  function  of  the  modelled  product. 

Independent  or  dependent  geometric  constructs  may  be  needed  in  addition  to  shape  defining  ele- 
ments to  specify  certain  types  of  tolerances.  Examples  of  these  are  hole  centerlines,  off-part  datums 
or  other  derived  geometries.  Therefore,  it  is  assumed  that  these  constructs  are  present/ available 
as  part  of  the  product  definition  model  for  reference  in  tolerances. 

All  tolerances  dimensions  are  derived  from  shape/size  elements  or  explicitly  stated  as  part  of 
implicit  features. 

Note  on  Model  Content 

This  version  of  the  Tolerance  Model  expands  on  two  concepts  which  are  only  cursorily  addressed 
in  earlier  versions;  dimensions  and  geometric  derivations.  Coordinate  Tolerances,  as  defined  in 
previous  versions  of  the  model,  contained  “extra”  data  that  was  intended  to  facilitate  the  determi- 
nation of  the  value  of  the  intended  dimension.  This  version  of  the  model  flips  the  emphasis  from 
the  tolerance  to  the  dimension;  coordinate  dimensions  are  defined  and  the  tolerance  values  are  the 
“extra”  data. 

Geometric  derivations  are  defined  to  accommodated  typical  dimension  practices  which  reference 
geometry  that  is  not  part  of  the  shape  definition  of  the  object  but  is  derivable  from  shape  elements. 
The  most  common  examples  are  centerlines  of  holes  and  the  spatial  intersection  of  two  part  siirfaces. 

Entity  numbers  used  are  local  only  to  this  model  and  are  included  for  bookkeeping/review 
purposes. 

This  model  constitutes  an  integration  of  version  2.1  of  the  model  and  the  results  of  the  interim 
meeting  15‘^  — February  1988  as  reported  in  the  techrucal  report  dated  25‘^  March  1988. 
Because  of  the  new  work,  some  entities  from  version  2.1  have  been  deleted  or  replaced.  Replacement 
entities  have  been  assigned  the  same  entity  number  as  the  entity  they  replaced.  New  entities  have 
been  assigned  new  number.  In  particular,  the  dimension  entities  have  been  assigned  numbers  in 
the  600’s. 

This  model  also  constitutes  an  integration  with  other  mature  topical  models.  The  work  of  the 
Integration  Committee  is  reflected  in  this  work. 

Note  on  Modelling  Conventions 

The  reference  model  presented  in  this  package  does  not  strictly  conform  to  IDEFlX  modelling 
techniques.  While  the  model  may  be  read  as  an  IDEFlX  model  from  a structural  point  of  view, 
the  following  conventions  have  been  adopted; 

1.  Key  attributes  have  not  been  defined.  The  Keys  in  the  model  are  strictly  identificational  (i.e. 
contaun  no  meaning)  and  are  included  to  illustrate  how  an  entity  “points  to”  a related  entity. 

2.  The  distinction  between  Identifying  and  Non-identifying  relationships  has  not  uniformly  been 
made.  All  relationships  in  this  model  may  be  considered  non-identifying.  This  does  not 
mean,  however,  that  the  existence  of  an  entity  will  not  depend  on  the  existence  of  some  other 
entity;  this  condition  stiU  may  exist.  Unless  an  attribute  has  been  defined  as  “Optional”, 


N288 


102 


ISO  TC184  5C4  WGl 


A N N E X D O cl 0 b ? r 3 1 1 ' 

(Draft  Proposal 

SECTION  3:  SHAPE  VARIATION  TOLERANCES 


the  attributes  of  an  entity  must  have  a value  when  the  entity  is  instanced  A '-'f  this 

convention  is  that  Dependent  and  Independent  entities  have  not  been  identified. 

3.  To  simplify  the  maintenance  of  the  model,  some  bberties  have  been  taken  with  the  entity 
numbering  scheme.  Where  entities  have  been  included  in  the  model  for  illustrative  purposes 
only  and  the  definition  or  existence  of  the  entity  is  not  important  to  the  tolerance  model,  then 
entity  is  given  an  asterisk(*)  rather  than  a number.  When  an  entity  had  to  be  categorized  due 
to  IDEFIX  syntax  constraints  (e  g.  TOL-ENT  = AREA-TOL-ENT  + SEAM-TOL-ENT 
FOS-TOL-ENT)  the  categorizations  are  given  the  same  entity  number  as  the  generic  parent. 

3.4  Glossary 

The  Definitions  provided  here  are  for  general  terms  which  are  not  defined  with  the  context  of  the 

model  (such  as  entity  and  attribute  definitions).  It  should  be  noted  that  some  of  the  definitions 

imply  scoping  statements  or  assumptions  made  about  the  model. 

Product  An  item(s)  which  is(are)  manufactured,  or  used  in  the  manufactirring  of  another  item. 

Product  Model  A digital  definition/representation  of  a product. 

Drawing  A pictorial  (image-based,  human  interpretable)  definition/  representation  of  a product. 

D imension  A measure  of  the  shape  of  product  that  specifies  a relationship  between  two  geometric 
elements  of  the  shape  definition  of  a product  or  a parameter  implicit  within  a geometric 
element.  The  numerical  value  of  the  dimension  is  implicit  within  the  model  geometry  or 
explicitly  called  out  in  an  implicit  feature. 

Feature  Feature  is  some  characteristic  of  an  object  or  an  object  representation  which  can  be 
uniquely  identified.  The  same  term  is  defined  more  completely  within  the  ANSI  standard. 

Object  Representation  Object  representation  refers  to  the  form  in  which  the  shape  of  a real  or 
conceived  object  is  defined. 

Design  Model  A Design  Model  is  the  complete  definition  of  a product,  typically  at  the  point  of 
“release”  to  manufacturing,  such  as  zm  engineering  drawing  or  product  model. 
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3.5  Subject  Reference  Model 
3.5.1  Entity  Pool 

This  is  a List  of  entities  contained  in  this  model:  (Underlined  entity  numbers  indicate  a diagram 
page  for  the  entity) 


Number 

Name 

603 

Angle  Dimension 

611 

Angle  Size  Characteristic 

609 

Angle  Size  Dimension 

610 

Angle  Size  Parameter 

4013 

Angle  Tolerance  Range 

406 

Angularity 

1023 

Angul-Proj-Tol-Zone 

506 

Angul-Tol-Ent 

5061 

Angul-Tol-Ent-Seam 

5062 

Angul-Tol-Ent -Area 

5063 

Angul-Tol-Ent-FOS 

INT-8 

Area 

311 

Center  of  Symmetry 

3111 

Center  of  Symmetry-Size 

3112 

Center  of  Symmetry-Angle 

508 

Circ-Tol-Ent 

5081 

Circ-Tol-Ent-Seam 

5082 

Circ-Tol-Ent- Area 

5083 

Circ-Tol-Ent-FOS 

407 

Circular  Runout 

408 

Circularity 

409 

Concentricity 

509 

Conc-Tol-Ent 

5091 

Cone- Tol-Ent- Seam 

5092 

Conc-Tol-Ent- Area 

5093 

Conc-Tol-Ent-FOS 

302 

Conditioned  Datum 

600 

Coordinate  Dimension 

401 

Coordinate  Tolerance  Range 

INT-20 

Corner 

507 

Crun- Tol-Ent 

Entity  Pool  in  Alphabetic  Order 
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Number 

Name 

5071 

Crun-Tol-Ent-Seam 

5072 

- 

Crun-Tol-Ent-Area 

5073 

- 

Crun-Tol-Ent-FOS 

6022 

- 

Curvi-Linear  Dim 

410 

- 

Cylindricity 

510 

- 

Cyl-Tol-Ent 

5102 

Cyl-Tol-Ent-Area 

5103 

Cyl-Tol-Ent-FOS 

301 

Datum 

6102 

Derivable  Angle  Size  Dimension 

6042 

Derivable  Size  Parameter 

109 

Derived  Geometry 

GE014 

Direction 

4151 

Directrix 

202 

DT  Area 

2_01 

DT  Corner 

300 

DT  Feature 

304 

DT  Form  Feature 

203 

DT  Seam 

20Q 

DT  Shape  Element 

306 

Feature  of  Size 

411 

Flatness 

511 

Flat-Tol-Ent 

FFOOl 

Form  Feature 

3061 

Form  Feature  of  Size 

110 

GD-Inputs 

111 

GD-Inputs-GD 

112 

GD-Inputs-SE 

113 

GD-Pairms 

108 

- 

Geometric  Derivation 

402 

- 

Geometric  Tolerance 

GEOl 

- 

Geometry 

FF002 

- 

Implicit  Form  Feature 

6101 

- 

Independent  Angle  Size  Dimension 

6041 

- 

Independent  Size  Parameter 

6021 

- 

Linear  Dimension 

602 

- 

Location  Dimension 

Entity  Pool  in  Alphabetic  Order  - (Continued) 
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Number 

Nai 

4012 

Location  Tolerance  Range 

412 

Parallelism 

1021 

Pari- P roj- Tol- Zone 

512 

Parl-Tol-Ent 

5121 

Pari- Tol-Ent- Seam 

5122 

Parl-Tol-Ent- Area 

5123 

Parl-Tol-Ent-FOS 

413 

Perpendicularity 

1022 

Perp-Proj-Tol-Zone 

513 

Perp-Tol-Ent 

5131 

Perp-Tol-Ent-Seam 

5132 

Perp-Tol-Ent- Area 

5133 

Perp-Tol-Ent-FOS 

515 

Plin-Tol-Ent 

5151 

Plin- Tol-Ent- Seam 

5152 

Plin-Tol-Ent- Area 

414 

Position 

1024 

Pos-Proj- Tol- Zone 

514 

Pos-Tol-Ent 

415 

Profile  of  a Line 

416 

Profile  of  a Surface 

102 

Projected -Tolerance -Zone 

516 

Psrf- Tol-Ent 

608 

Related  Angle  Dimension 

INT-14 

Seam 

3031 

SF-Components 

INT-2 

Shape-Element 

400 

Shape. Tolerance 

605 

Size  Characteristic 

m 

Size  Dimension 

303 

Size  Feature 

604 

Size  Parameter 

4011 

Size  Tolerance  Range 

4171 

Straight-Direction 

417 

Straightness 

517 

Strght-Tol-Ent 

Entity  Pool  in  Alphabetic  Order  - (Continued) 
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Number 

5171 

Strght-Tol-Ent-Seam 

5172 

Strght-Tol-Ent-Area 

5173 

Strght-Tol-Ent-FOS 

418 

Total  Runout 

518 

Trun-Tol-Ent 

5182 

Trun-Tol-Ent-Area 

5183 

Trun- Tol- Ent  - FO  S 

310 

Unconditioned  Datum 

Name 


Entity  Pool  in  Alphabetic  Order  - (Continued) 


Number 

Na: 

IQl 

Direction 

102 

Projected  Tolerance  .Zone 

1021 

Pari- Proj- Tol- Zone 

1022 

Perp-Proj- Tol- Zone 

1023 

Angul- Proj- Tol- Zone 

1024 

Pos-Proj-Tol-Zone 

108 

Geometric  Derivation 

109 

Derived  Geometry 

no 

GD-Inputs 

111 

GD-Inputs-GD 

112 

GD-lnputs-SE 

113 

GD-Paxms 

200 

DT  Shape  JElement 

201 

DT  Corner 

202 

DT  Seam 

20_3 

DT  Area 

3110 

DT-Feature 

301 

Datum 

302 

Conditioned  Datum 

303 

Size  Feature 

Entity  Pool  in  Numeric  Order 
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Number 

Name 

304 

- 

DT  Form  Feature 

3031 

- 

SF-Components 

306 

- 

Feature  of  Size 

3061 

- 

Form  Feature  of  Size 

310 

- 

Unconditioned  Datum 

m 

- 

Center  of  Symmetry 

3111 

- 

Center  of  Symmetry-Size 

3112 

- 

Center  of  Symmetry-Angle 

400 

- 

Shape-Tolerance 

401 

- 

Coordinate  Tolerance  Range 

4011 

- 

Size  Tolerance  Range 

4012 

- 

Location  Tolerance  Range 

4013 

- 

Angle  Tolerance  Range 

402 

- 

Geometric  Tolerance 

406 

- 

Angularity 

407 

- 

Circular  Runout 

408 

- 

Circularity 

409 

- 

Concentricity 

410 

- 

Cylindricity 

411 

- 

Flatness 

412 

- 

Parallelism 

413 

- 

Perpendicularity 

414 

- 

Position 

415 

- 

Profile  of  a Line 

4151 

- 

Directrix 

416 

- 

Profile  of  a Surface 

117 

- 

Straightness 

4171 

- 

Straight-Direction 

418 

- 

Total  Runout 

506 

- 

Angul-Tol-Ent 

5061 

- 

Angul-Tol-Ent-Seam 

5062 

- 

Angul-Tol-Ent- Area 

5063 

- 

Angul-Tol-Ent-FOS 

507 

- 

Crun-Tol-Ent 

5071 

- 

Cnm-Tol-Ent-Seam 

5072 

- 

Crun-Tol-Ent -Area 

5073 

- 

C rtm- Tol- Ent  - F 0 S 

Entity  Pool  in  Numeric  Order  - (Continued) 
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Number 

508 

Circ-Tol-Ent 

5081 

- 

Circ-Tol-Ent-Seam 

5082 

- 

Circ-Tol-Ent-Area 

5083 

- 

Circ-Tol-Ent-FOS 

509 

- 

Conc-Tol-Ent 

5091 

- 

Conc-Tol-Ent-Seam 

5092 

- 

Conc-Tol-Ent- Area 

5093 

- 

Conc-Tol-Ent -EOS 

510 

- 

Cyl-Tol-Ent 

5102 

- 

Cyl-Tol-Ent-Area 

5103 

- 

Cyl-Tol-Ent-FOS 

511 

- 

Flat-Tol-Ent 

512 

- 

Parl-Tol-Ent 

5121 

- 

Parl-Tol-Ent-Seam 

5122 

- 

Parl-Tol-Ent- Area 

5123 

- 

Parl-Tol-Ent-FOS 

513 

- 

Perp-Tol-Ent 

5131 

- 

Perp-Tol-Ent-Seam 

5132 

- 

Perp-Tol-Ent -Area 

5133 

- 

Perp-Tol-Ent -FOS 

514 

- 

Pos-Tol-Ent 

515 

- 

Plin-Tol-Ent 

5151 

- 

Plin-Tol-Ent-Seam 

5152 

- 

Plin-Tol-Ent- Area 

516 

- 

Psrf-Tol-Ent 

517 

- 

Strght-Tol-Ent 

5171 

- 

Strght-Tol-Ent-Seam 

5172 

- 

Strght-Tol-Ent- Area 

5173 

- 

Strght-Tol-Ent-FOS 

518 

- 

Trun-Tol-Ent 

5182 

- 

Trun-Tol-Ent-Area 

5183 

- 

Trun-  Tol-  Ent  - F 0 S 

600 

- 

Coordinate  Dimension 

601 

- 

Size  Dimension 

602 

- 

Location  Dimension 

6021 

- 

Linear  Dimension 

6022 

- 

Curvi-linear  Dim 

Entity  Pool  in  Numeric  Order  - (Continued) 


no 


ISO  TC184  SC4  WGl 


October  31,  1988 


N288 


ANNEX  D 
(Draft  Proposal 

SECTION  3:  SHAPE  VARIATION  TOLERANCES 


Number 

Name 

603 

Angle  Dimension 

604 

Size  Parameter 

6041 

Independent  Size  Parameter 

6042 

Derivable  Size  Parameter 

605 

Size  Characteristic 

608 

Related  Angle  Dimension 

609 

Angle  Size  Dimension 

610 

Angle  Size  Parameter 

6101 

Independent  Angle  Size  Dimension 

6102 

Derivable  Angle  Size  Dimension 

611 

Angle  Size  Characteristic 

FFOOl 

Form  Feature 

FF002 

Implicit  Form  Feature 

GEOl 

Geometry 

GE014 

Direction 

INT-2 

Shape  Element 

INT-8 

Area 

INT-14 

Seam 

INT-20 

Corner 

Entity  Pool  in  Numeric  Order  - (Continued) 
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3.5.2  Entity  Definitions 

The  entity  definitions  which  constitute  this  model  are  presented  (more  or  less)  in  the  IDEF  subject- 
entity  diagram  and  page-pair  format  with  additional  formatting  as  follows: 

Entity  Number  and  Name; 

The  entity  number  is  local  to  this  model  (i.e.  do  not  correspond  to  any  other  models.) 

Entity  Definition; 

The  definition  of  the  entity  is  relative  to  its  use  in  the  model. 

Express  Definition  of  Entity: 

The  (more-or-less)  equivalent  Express  definitions  for  the  IDEFIX  model  have  been  provided  in  this 
model.  This  includes  those  entities  which  were  defined  as  parts  of  other  modelling  efforts  (i.e.  fall 
within  the  scope  of  other  reference  models). 

Definition  of  Attributes: 

Where  attributes  have  been  defined  for  entities  (not  including  all  cases  of  migrated  keys),  a definition 
is  provided  for  each  attribute. 

Definition  of  Constraints; 

Where  specific  constraints  on  the  value  of  an  attribute  or  existance  of  a relationship  are  known,  an 
explanation  of  the  constraint  is  provided  to  support  the  statements  in  the  WHERE  portion  of  the 
Express  definition  of  the  entity. 

Propositions  (a.k.a.  Business  Rules): 

Propositions  are  statements  of  fact  about  the  subject  entity  and  its  relationships  to  other  entities. 
They  aire  English-language  statements  of  the  relationships  defined  in  the  model.  Sometimes  propo- 
sitions contain  knowledge  about  the  entity  that  cannot  be  captured  in  the  IDEFIX  or  Express 
definitions. 

Subject  Entity  Diagram; 

The  IDEFIX  model  of  the  entity  which  is  being  defined. 

Declarations; 

A number  of  attribute  types  and  constraints  are  specified  more  than  several  times  throughout  the 
following  entity  definitions.  The  ones  which  occur  most  frequently  are  explained  here: 
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TYPE 

Tol.MLSN  : ENUMERATION  OF  (MAXMC,  LEASTMC , REGARDLESS,  NONE); 

Tol.IBO  : ENUMERATION  OF  (INSIDE,  BILATERAL,  OUTSIDE): 

CONSTRAINTS 
Tol.Ent  <>  []  : 

Tol-Ent  is  a SET  containing  the  entities  to  which  a tolerance  applies.  This  constraint  specifies  that 
that  set  must  not  be  empty.  This  is  true  for  all  tolerance  entities  which  use  the  SET  except  for 
Profile  of  a Surface,  where  the  set  may  be  empty  if  the  tolerance  is  a default  tolerance 

IF  SYMMETRIC(object)  THEN 
Material.Condition  = M OR 
Material_Condition  = L OR 

Material.Condition  = S;  --  Default  condition 

ELSE 

Material.Condition  = N; 


This  contraint  states  that  if  an  “object”  (an  entity,  or  members  of  an  input  LIST,  SET,  or  ARRAY) 
is  Symmetric  about  a point,  curve  or  surface,  then  an  associated  Material-Condition  modifier  must 
have  a value  M,  L or  S.  If  the  object  is  not  symmetric,  then  a Material-Condition  modifier  is  not 
applicable  and  should  be  N. 

Tolerance  > 0.0; 

The  meaning  of  this  constraint  is  self-evident. 


113 


ISO  TC184  SC4  WG  1 


ANNEX  D 
(Draft  Proposal 


October  31.  l?8r  N288 


SECTION  3:  SHAPE  VARIATION  TOLERANCES 


Entity  Name;  Direction 

Entity  Number;  GEO-14 

A sequence  of  three  values  that  define  a unit  vector  which  specifies  a direction  in  cartesain 
space.  The  Euclidean  norm  is  exactly  1. 

This  entity  falls  within  the  scope  of  the  Geometry  model,  but  is  included  here  for  completeness. 
The  definition  provided  implies  the  requirements  that  the  Tolerance  Model  has  of  the  entity. 

EXPRESS  Definition 

ENTITY  Direction  SUBTYPE  OF  (Wire.Frame.Geometry ) ; 

X : Number; 

Y : Number; 

Z : Optional  Number; 

WHERE 

(X**2  + Y**2  + Z**2)  = 1.0; 

END. ENTITY; 


Propositions: 

Each  Direction(GEO-14) 

• defines  the  direction  of  0.1,  or  more  Projected-Tolerance-Zone(102). 

• defines  0,1  or  more  Directrix’s  (4151)  which  are  the  normals  for  the  planes  which  define 
Profile-Line(415)  tolerances. 

• defines  0,  1 or  more  directions  (4171)  of  application  for  Straightness(417)  tolerances. 

• establishes  the  right  hand  rule  for  0,1,  or  more  Related  Angle  Dimension  (608). 
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Entity  Name;  Projected-Tolerance-Zone 
Entity  Number;  102 

A Projected-Tolerance-Zone  is  a direction  and  a length  value  which  establishes  the  extent  of 
the  projected  tolerance  zone. 

EXPRESS  Definition 

ENTITY  Projected.Tolerance.Zone ; 

Direction  : Direction; 

Extent  : Number: 

WHERE 

MEMBERCPosition , 1 , 1 ) OR  MEMBERf Angularity , 1 , 1 ) OR 

MEMBERCParallelism , 1 , 1 ) OR  MEMBERCPerpendicularity , 1 , 1 ) ; 

(*  Parallel (Direction , {Curve  or  Surface  of  Symmetry  of 

Toleranced  Entity});  *) 

Extent  > 0.0; 

END. ENTITY; 


Attribute  Definition: 

Direction 

The  direction  from  the  tolerance  zone  defined  by  the  tolerance  entity  that  the  additional 
tolerance  zone  is  projected.  This  direction  must  be  parallel  to  the  curve  or  surface  of  symmetry 
of  the  toleranced  entity  (if  it  is  a Feature  of  Size)  or  the  toleranced  entity  itself  (if  not  a Feature 
of  Size). 

Extent 

A real  value  that  specifies  the  length  of  the  projected  tolerance  zone. 

Constraint: 

MEMBERCPosition, 1,1)  OR  MEMBER(Angularity , 1 , 1)  OR 
MEMBERCParallelism, 1 , 1)  OR  MEMBERCPerpendicularity , 1 , 1 ) ; 


For  the  existence  of  a Projected-Tolerance-Zone  (PTZ)  to  be  valid,  it  must  be  related  to  a Posi- 
tion(414),  AnguJeLrity(406),  ParalleLism(412),  or  Perpendicularity(413)  Tolerance. 

Parallel (Direction , {Curve  or  Surface  o.  Toleranced  Entity}) 

The  direction  of  the  PTZ  must  be  parallel  to  the  curve  or  surface  of  symmetry  if  the  toleranced 
entity  is  a Feature  of  Size,  or  parallel  to  the  toleramced  entity  itself. 
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DEFINES 


DIRECTRIX/4151 


DIRECTION/GFQI 4 


OIR-IO 


X.  Y.  Z 


DEFINES  DIRECTION  OF 


PR^ECTED- TOLERANCE -ZONE  / 102 


DEFINES 


1 


STRAIGHT-DIRECTIDN/4 I 7 1 


6 ESTABLISHES  RHR  FOR 


RELATED  ANGLE  D IMENS I ON/ 6^8 


Figtire  D-1:  DIRECTION  IDEFIX  Diagram 
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Propositions: 

Each  Project-Tolerance- Zone(  102) 

• is  directed  by  exactly  one  Direction(GEO-14). 

• defines  the  projected  tolerance  zone  for  0 or  1 Perpendicularity(413)  tolerance. 

• defines  the  projected  tolerance  zone  for  0 or  1 Angularity(406)  tolerance. 

• defines  the  projected  tolerance  zone  for  0 or  1 Position(414)  tolerance. 

• defines  the  projected  tolerance  zone  for  0 or  1 Parallelism(412) 

• must  define  a projected  toleramce  zone  for  a tolerance. 
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Entity  Name;  Geometric  Derivation 

Entity  Number:  108 

A Geometric  Derivation  is  a geometric  entity  which  is  derived  from  shape  representation  ele- 
ments. An  actual  entity  corresponding  to  this  geometric  derivation  may  or  may  not  be  included  in 
the  design  model.  The  key  distinction  is  that  the  geometric  derivation  is  not  a definitional  element 
of  the  shape  of  an  object,  but  is  determined  from  shape  elements  or  other  geometric  derivations. 
On  an  actual  physicad  object  the  geometric  derivation  is  virtual  geometry  that  is  calculated  from 
reference  to  “hard  points”  on  the  object  (faces,  edges  and  vertices  on  the  physical  object  which 
correspond  to  the  areas,  seauns  auid  corners  in  the  object  representation).  Examples  include,  cen- 
terlines amd  centerplanes;  breakout  tangency  planes;  spacial  intersection  of  two  surfaces. 

A Geometric  Derivation  is  a feature  which  may  be  used  as  the  target  or  the  origin  of  a toler- 
ance/ dimension. 

A Geometric  Derivation  consist  primarily  of  the  shape  elements  of  other  Geometric  Derivations 
used  to  determine  the  derived  geometry,  and  a type  designation  indicating  the  type  of  derivation 
A reference  to  the  derived  geometry  may  optionally  be  included. 

EXPRESS  Definition 

ENTITY  Geometric. Derivation  SUBTYPE  OF  (DT.Feature) : 

Type  : Undefined; 

Parameters  : LIST  OF  SELECTCShape.Element , 

Geometric.Derivation) ; 

Derived.Geometry  : Optional  Geometry: 

END.ENTITY; 


Attribute  Definition: 

Type 

A (to  be)  enumerated  list  of  operations  that  result  in  specified  types  of  geometry  which 
are  derived  from  the  input  parameters.  Each  operation  would  consist  of  an  input  list  of 
parameters,  the  anticipated  type  of  result,  and  an  algorithmic  description  of  the  operation. 

Parameters 

The  inputs  to  the  derivation  operation.  Most  typically  the  parameters  will  be  shape  element 
entities  from  which  the  geometry  is  derived. 

Deri  ved-  Geometry 

The  evaluated  form  of  the  Geometric  Derivation  may  be  included  for  completeness.  The 
result  of  the  derivation  operation,  however,  takes  precedence  over  a predefined  result  that  is 
included  in  the  definition  of  the  entity. 
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Entity  Name;  DT-Shape-Element 

Entity  Number:  200 

Shape  elements  or  entities,  within  the  scope  of  this  model,  are  constructs  that  define  touchable 
or  viewable  portions  of  a part.  Shape  elements  are  defined  in  various  ways  depending  the  type  of 
shape  representation  method  used.  A DT-Shape-Element  is  a subset  of  Shape  Element  which  is 
defined  for  the  purposes  of  this  model. 

Shape  Element  entity  is  outside  the  scope  of  the  tolerance  model  but  is  included  for  integration 
reasons,  it  falls  within  the  scope  of  the  w-ork  of  the  PDES  Integration  Committee. 

EXPRESS  Definition 

ENTITY  DT.Shape.Element  SUPERTYPE  OF  (Area,  Seaun,  Corner); 

END.ENTITY; 


Propositions: 

Each  DT-Shape-Element(200) 

• must  be  of  one  Shape-Element  type 

• may  be  a Corner(INT-20). 

• may  be  a Seam(INT- 14). 

• may  be  a Area(INT-8). 

• may  be  a component  of  the  Size  Feature(303). 

• is  a DT  Feature(300). 

Constrai nt  Definition 

A Comer  may  not  be  a component  of  a Size  Feature(303). 
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Entity  Name:  Corner  (formerly  Vertex) 

Entity  Number;  INT-200 

A corner  defines  a unique,  zero-dimensional  location  on  the  shape  of  the  product. 

Corner  is  outside  the  scope  of  the  Tolerance  Model,  but  is  included  for  completeness  and  inte- 
gration reasons.  It  properly  falls  within  the  scope  of  the  work  of  the  Integration  Commitlee,  see 
that  work  for  a complete  definition  of  this  entity.  The  definition  here  is  incomplete  with  respect  to 
the  work  of  the  Integration  Committee,  but  is  sufficient  for  the  purposes  of  this  model. 

EXPRESS  Definition 

ENTITY  Corner  SUBTYPE  OF  (DT.Shape. Element) ; 

END.ENTITY; 
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Entity  Name:  Seam 

Entity  Number:  104 

A seam  is  a one- dimensional  characteristic  of  the  shape  of  a product,  typically  defined  by  the 
intersection  of  two  areas  and  bounded  by  two  corners. 

Seam  is  outside  the  scope  of  the  Tolerance  Model,  but  is  included  for  completeness  and  integra- 
tion reasons.  It  properly  falls  within  the  scope  of  the  work  of  the  Integration  Committee;  see  that 
work  for  a complete  definition  of  this  entity.  The  definition  here  is  incomplete  with  respect  to  the 
work  of  the  Integration  Committee,  but  is  sufficient  for  the  purposes  of  this  model. 

EXPRESS  Definition 

ENTITY  Seam  SUBTYPE  OF  (DT.Shape.Element ) ; 

END.ENTITY; 

Propositions: 

Each  Seam(INT-14) 

• is  a Shape-Element(200). 

• can  be  toleranced  by  0 or  1 Angularity(406)  tolerance. 

• can  be  toleranced  by  0 or  1 Circularity(408)  tolerance. 

• can  be  toleranced  by  0 or  1 CircuJar-Runout(407)  tolerance. 

• can  be  toleranced  by  0 or  1 Concentricity(409)  tolerance. 

• can  be  toleranced  by  0 or  1 Parallelism(412)  tolerance. 

• can  be  toleranced  by  0 or  1 Perpendicularity(413)  tolerance. 

• can  be  toleranced  by  0 or  1 Profile-Line(415)  tolerance. 

• can  be  toleranced  by  0 or  1 Straightness(417)  tolerance. 
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Entity  Name:  Area 

Entity  Number:  INT-8 

An  area  is  a two-dimensional  characteristic  of  the  shape  of  a product,  and  is  a bounded  portion 
of  a geometric  surface. 

Area  is  outside  the  scope  of  the  Tolerance  Model,  but  is  included  for  completeness  and  integra- 
tion reasons.  It  properly  falls  within  the  scope  of  the  work  of  the  Integration  Committee;  see  that 
work  for  a complete  definition  of  this  entity.  The  definition  here  is  incomplete  with  respect  to  the 
work  of  the  Integration  Committee,  but  is  sufficient  for  the  purposes  of  this  model. 

EXPRESS  Definition 

ENTITY  Area  SUBTYPE  OF  (DT.Shape. Element ) ; 

END.ENTITY; 

Proposition: 

Each  Area(INT-8) 

• is  a Shape-Element(INT-8). 

• can  be  toleranced  by  0 or  1 Angularity(406)  tolerance. 

• can  be  toleranced  by  0 or  1 Circularity (407)  tolerance. 

• can  be  toleranced  by  0 or  1 Circular-Runout(408)  tolerance. 

• can  be  toleranced  by  0 or  1 Concentricity(409)  tolerance. 

• can  be  toleranced  by  0 or  1 Cylindricity(410)  tolerance. 

• can  be  toleranced  by  0 or  1 Flatness(411)  tolerance. 

• can  be  toleranced  by  0 or  1 Par3Jlelism(412)  tolerance. 

• can  be  toleranced  by  0 or  1 Perpendicularity(413)  tolerance. 

• can  be  toleranced  by  0 or  1 Profile-Line(415)  tolerance. 

• can  be  toleranced  by  0 or  1 Profile-Surface(416)  tolerance. 

• can  be  toleranced  by  0 or  1 Straightness(417)  tolerance. 

• can  be  toleranced  by  0 or  1 Total-Runout(418)  tolerance. 
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Entity  Name;  DT-Feature  (formerly  Feature) 

Entity  Number;  300 

A Dimension/Tolerance  Feature  is  a categorization  of  things  which  may  be  the  target  or  origin 
of  dimension/ tolerances  and  corresponds  to  the  term  “feature”  as  used  in  the  ANSI  Y14.5  standard. 
It  is  some  characteristic  of  the  shape  of  a product  that  can  be  uniquely  identified.  Categories  of 
a DT  Feature  include:  Shape  Elements  (Area,  Seam,  Corner),  Form  Features,  Features  of  Size  (a 
subset  of  which  are  Form  Features),  and  Geometric  Derivations.  Angle  and  Location  Dimensions 
reference  DT  Features  and  Size  Dimensions  reference  Features  of  Size.  It  is  an  artificial  classification 
defined  for  the  purposes  of  the  Tolercince  Model. 

EXPRESS  Definition 

ENTITY  DT.Feature  SUPERTYPE  OF  (DT.Shape.Element , DT.Form.Feature , 
Feature.of  .Size  , Geometric.Derivation'^  ; 

END.ENTITY; 


Propositions; 

A DT-Feature(300) 

• may  be  the  target  of  a Location  Dimension  (602). 

• may  be  the  origin  of  a Location  Dimension  (602). 

• may  be  the  target  of  a Related  Angle  Dimension  (608) 

• may  be  the  origin  of  a Related  Angle  Dimension  (608). 

• may  be  used  as  a DatiuTi(301). 

• must  be  a DT-Shape-Element(200),  DT-Form-Feature(304),  Feature-of-Size(306),  or  a Geometric- 
Derivation(  108). 
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Figure  D-7:  DT  AREA  / AREA  IDEFIX  Diagram 
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Entity  Name:  Datum 

Entity  Number:  301 

A theoretically  exact  geometric  reference  to  which  toleranced  features  are  related 

EX  PR  ESS  Definition 

ENTITY  Datum; 

Reference  : DT.Feature; 

Name  : String(2) ; 

WHERE 

(* *  Note  constraint  on  Name  A..Z,  AA..ZZ  Except  I,  0,  0 ♦) 
END. ENTITY; 


Attribute  Definitions: 

Reference 

An  entity  which  serves  as  the  exact  definition  of  the  datum. 

Name 

An  alphabetic  string  that  provides  a unique  designation  for  the  datum  (range:  A . . . Z. 
AA  . . . ZZ,  excluding  I,  0,  and  Q) 

Proposition: 

Each  Datum(301) 

• is  defined  by  a DT-Feature(300). 

• may  be  a Conditioned-Datum(302). 

• may  be  an  Unconditioned-Datum(310). 
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Entity  Name;  Conditioned  Datum 

Entity  Number;  302 

A conditioned  datum  is  a datum  to  which  a material  condition  modifier  may  apply  (if  the  datum 
is  defined  by  a Feature  of  Size). 

EXPRESS  Definition 

ENTITY  Conditioned.Datmn  SUBTYPE  OF  (Datum) ; 

Material_condition  : Tol.MLSM; 

WHERE 

IF  (SYMMETRICCDatum. Reference)  THEN 
Material.Condition  = M OR 
Material.Condition  = L OR 
Material.Condition  = S; 

ELSE 

Material.Condition  = N; 

END. ENTITY; 


Attribute  Definitions; 

Material-condition 

An  enumerated  list  that  indicates  the  material  condition  at  which  the  tolerance  applies: 

M - maximum  material  condition;  L - least  material  condition;  or  S - regardless  of  feature 
size;  N - not  applicable. 

Propositions: 

Each  Conditioned  Datum(302) 

• is  a Datum(301). 

• is  the  primary  datum  for  0,  1,  or  more  Angularity(406)  Tolerances. 

• is  the  secondary  datum  for  0,  1,  or  more  Angularity(406)  Tolerances. 

• is  the  tertiary  datum  for  0,  1,  or  more  Angularity(406)  Tolerances. 

• is  the  primary  datum  for  0,  1,  or  more  Profile-Line(415)  Tolerances. 

• is  the  secondary  datum  for  0,  1,  or  more  Profile-Line(415)  Tolerances. 

• is  the  tertiary  datum  for  0,  1,  or  more  Profile-Line(415)  Tolerances. 

• is  the  primary  datum  for  0,  1,  or  more  Parallelism(412)  Tolerances. 
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• is  the  primary  datum  for  0,  1,  or  more  PerpendicuJarity(413)  Tolerances 

• is  the  secondary  datum  for  0,  1,  or  more  Perpendicularity(415)  Tolerances 

• is  the  primary  datum  for  0,  1,  or  more  Position(414)  Tolerances. 

• is  the  secondary  datum  for  0,  1,  or  more  Position(414)  Tolerances. 

• is  the  tertiary  datum  for  0,  1,  or  more  Position(414)  Tolerances 

• is  the  Primary  datum  for  0,  1,  or  more  Profile-Surface(416)  Tolerances. 

• is  the  secondary  datum  for  0,  1,  or  more  Proflle-Surface(416)  Tolerances. 

• is  the  tertiary  datum  for  0,  1,  or  more  Profile-Surface(416)  Tolerances. 
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Entity  Name;  Size  Feature 
Entity  Number;  303 

A collection  of  Areas  which  has  a tolerancable  geometric  location  that  is  derived  from  physi- 
cal feature  geometry  and  is  symmetrical  about  that  geometric  location  (e.g.  point,  axis,  curve  or 
surface.)  This  entity  exists  because  a set  of  Form  Features  has  not  been  fully  defined.  A subset 
of  Form  Features  can  be  classified  as  Features-of-Size  (e.g.  Hole,  Tab,  Slot)  and  the  concept  of 
Feature-of-Size  is  required  for  tolerancing.  This  construct  will  allow  the  application  of  tolerances 
to  shape  definitions  which  to  not  included  Form  Features. 


NOTE;  The  number  of  Areas  used  to  define  a Size-Feature  depends  on  the  particular  imple- 
mentation of  the  shape  representation.  In  some,  a single  surface  which  wraps  around  to  form  a 
cylinder  and  joins  itself  at  a seam  would  be  an  appropriate  single  component  of  a Size-Feature. 
The  assumption  here  is  that  it  would  take  at  least  two  semi-cylindrical  surfaces  to  define  a hole 
Size-Feature. 

EXPRESS  Definition 

ENTITY  Size.Feature  SUBTYPE  OF  (Feature. of. Size) ; 

SF. Components  : LIST  [2  to  #]  of  SELECT(Area,  Seam); 

WHERE 

SYMMETRICCSF. Components) ; 

(* *  All  members  of  LIST  must  be  of  same  type.  *) 

END. ENTITY: 


Propositions: 

Each  Size  Feature(303) 

• is  a type  of  Feature-of-Size(306). 

• is  composed  of  2 or  more  Areas(INT-8)  or  2 or  more  Seams(INT-14). 
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Figure  D-10;  CONDITIONED  DATUM  IDEFIX  Diagram 
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Entity  Name;  DT-Form-feature,  Implicit  Form  Feature,  Form  Feature 

Entity  Number;  304,FF-002,FF-001 

A referencable  collection  of  shape  elements  whose  name  implies  some  stereotypical  configuration. 
Form  Feature  and  Implicit  Form  Feature  entity  are  outside  the  scope  of  the  Tolerance  Model, 
but  are  included  for  integration  reasons.  The  definition  of  the  entity  is  with  respect  to  and  from 
the  viewpoint  of  the  Tolerance  Model  and  is  incomplete  with  respect  to  the  Form  Features  model. 

The  inclusion  of  the  this  entity  within  the  Tolerance  Model  should  be  regarded  as  a Planning 
Level  View.  That  is,  the  relationship  between  Implicit  Form  Feature  and  the  tolerance  entities 
within  the  Tolerance  Model  will  correspond  to  relationships  between  tolerance  entities  and  Specific 
Implicit  Features  (e.g.  Implicit-Thru-Hole)  in  the  Form  Features  Model. 

EXPRESS  Definition 

ENTITY  DT.Form. Feature  SUBTYPE  OF  (DT. Feature) ; 

Ref.Feature  : Form.Feature ; 

END.ENTITY; 

Propositions; 

Each  DT  Form  Feature(304) 

• is  a DT  Feature 

• may  be  a Form  Feature  (FF-001). 

• can  be  used  as  Form  Feature  of  Size  (3061). 

Each  Implicit  Form  Feature  (FF-002) 

• is  defined  by  0,  1,  or  more  Size  Parameters  (604). 

• is  defined  by  0,  1,  or  more  Angle  Size  Parameter  (610). 
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Entity  Name:  Feature-of-Size 

Entity  Number:  306 

A Feature  of  Size  is  a grouping  of  Areas  or  Seams  which  are  characterized  by  a set  of  opposing 
Areas  or  Seams  and  a point,  curve  (or  axis),  or  surface  of  symmetry.  It  has  two  subsets:  1)  all 
defined  Size  Features(303)  are  Features  of  Size(306)i  2)  all  Form  Features  which  have  been  defined 
as  Features  of  Size(306)  (e  g.  hole,  tab,  slot). 

EXPRESS  Definition 

ENTITY  Feature.of.Size  SUBTYPE  OF  (DT. Feature) ; 

Type  : Enumeration  of  (Form.Feature , Size.Feature) ; 

FF  : Optional  DT_Form_Feature ; 

WHERE 

SYMMETRIC(FF) ; 

IF  (Type  = Form.Feature ) THEN  FF  <>  NULL; 

IF  (Type  = Size.Feature.  THEN  FF  = NULL; 

END. ENTITY. 

Attribute  Definition: 

Type 

A Feature  of  Size  is  either  a Size  Feature  or  a Form  Feature  which  is  a symmetric  about  a 
point,  curve  or  surface. 


FF 

If  a Form  Feature  is  a Feature  of  Size,  then  it  must  be  identified  as  such. 

Constraint  Definition: 

SYMMETRIC(FF) 


If  the  Form  Feature  is  a Feature  of  Size,  then  it  must  be  symmetric. 

IF  (Type  = Form-Feature)  THEN  FF  <>  NULL: 

IF  (Type  = Size-Feature)  THEN  FF  = NULL; 


If  the  Feature  of  Size  is  a Form  Feature,  then  the  FF  attribute  must  reference  some  Form  Feature. 
If  it  isn’t,  if  it  is  a Size  Feature,  the  the  FF  attribute  must  be  NULL. 
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Figure  D-12;  DT  FORM  FEATURE  IDEFlX  Diagram 
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Propositions: 

Each  Feature-of-Size(306) 

• is  a DT  Feature  (300). 

• may  be  a Size-Feature(303). 

• may  be  a DT  Form  Feature  (304). 

• can  be  toleramced  by  0 or  1 Angularity  Tolerance  (406). 

• can  be  toleranced  by  0 or  1 Circular  Runout  Tolerance  (407). 

• can  be  toleranced  by  0 or  1 Circularity  Tolerance  (408). 

• can  be  toleranced  by  0 or  1 Concentricity  Tolerance  (409). 

• can  be  toleranced  by  0 or  1 Cylindricity  Tolerance  (410). 

• can  be  toleranced  by  0 or  1 Parallelism  Tolerance  (412). 

• can  be  toleranced  by  0 or  1 Perpendicularity  Tolerance  (413) 

• can  be  toleranced  by  0 or  1 Position  Tolerance  (414) 

• can  be  toleranced  by  0 or  1 Straightness  Tolerance  (417). 

• can  be  toleranced  by  0 or  1 Total  Runout  Tolerance  (418). 

• has  0,1)  or  more  Size  Characterisitic  (605). 

• has  0,  1,  or  more  Angle  Size  Characteristic  (611). 

• must  have  at  least  one  Size  (605)  or  Angle  Size  Characteristic  (611). 
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Figure  D-13;  FEATURE  OF  SIZE  IDEFIX  Diagram 
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Entity  Name;  Unconditioned  Datum 

Entity  Number;  310 

An  Unconditioned  Datum  is  a Datum  to  which  a Material  Condition  Modifier  (MCM:  MMC, 
LMC,  RFS)  does  not  apply. 

EXPRESS  Definition 

ENTITY  Unconditioned.Datmn  SUBTYPE  OF  (Datum) ; 

END.ENTITY; 

Propositions: 

Each  Unconditioned  Datum(310) 

• is  a Datum(301 ). 

• is  the  primary  datum  for  0,  1,  or  more  Total-Runout(418)  Tolerances. 

• IS  the  co-datum  for  0,  1,  or  more  Total-Runout(418)  Tolerances. 

• is  the  primary  datum  for  0,  1,  or  more  Circular-Runout(407)  Tolerances. 

• is  the  co-datum  for  0,  1,  or  more  Circuiar-Runout(407)  Tolerances. 

• is  the  primary  datum  for  0,  1,  or  more  Concentricity(409)  Tolerances. 

• is  the  co-datum  for  0,  1,  or  more  Concentricity(409)  Tolerances. 
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Entity  Name:  Center-of-Symmetry 

Entity  Number;  311 

Features  of  Size  are  characterized  by  a center  of  symmetry.  The  center  of  symmetry  may  be  a 
point,  curve,  axis  or  surface  about  which  the  elements  of  the  Feature  of  Size  are  symmetric. 

This  is  an  IDEFIX  intersection  entity  and  does  not  manifest  itself  as  an  Express  Entity.  Cen- 
ter of  Symmetry  is  a role  (attribute  name)  that  a geometric  entity  plays  with  respect  to  a Size 
Dimension  and  an  Angle  Size  Dimension. 

Propositions; 

Each  Center  of  Symmetry(31 1 ) 

• is  defined  by  exactly  one  Geometry  (GEO-1). 

• is  part  of  1 or  more  Size  Characteristic  (605) 

• IS  part  of  1 or  more  Angle  Size  Characteristic  (611) 

• must  be  part  of  one  Size  Characteristic  OR  one  Angle  Size  Characteristic. 
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Figure  D-14:  UNCONDITIONED  DATUM  IDEFIX  Diagram 
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Entity  Name;  Shape.Tolerance 

Entity  Number;  400 

The  allowable  deviation  of  a geometric  aspect  of  a product  from  its  design  nominal  geometry. 

EXPRESS  Definition: 

ENTITY  Shape.Tolerance  SUBTYPE  OF  (Tolerance): 

END.ENTITY; 

Propositions: 

Each  Shape-Tolerance(400) 

• may  be  a Geometric-Tolerance(402). 

• may  be  a Coordinate  Tolerance  Jl.ange(401 ). 

• must  be  a Geometric  Tolerance  or  a Coordinate  Tolerance  Range. 

• is  a Tolerance. 
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Figure  D-15:  CENTER  OF  SYMMETRY  IDEFIX  Diagram 
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Entity  Name;  Coordinate-Tolerance_Range 
Entity  Number;  401 

A Coordinate.ToleranceJlange  is  the  numeric  values  added  to  and  subtracted  from  the  nominal 
dimensional  value  calculate  from  the  shape  definition  of  a product.  Coordinate  Tolerance. Range 
represent  the  traditional  plus/minus  tolerances  fotmd  on  dimensions  on  drawings. 

EXPRESS  Definition: 

ENTITY  Coordinate_Tolerance_Range  SUBTYPE  OF  (Shape.Tolerance) ; 

Plus.Tol  : Number; 

Minus.Tol  : Number; 

WHERE 

Plus.Tol  > 0.0; 

Minus.Tol  >0.0; 

NOT  ((Plus.Tol  = 0.0)  AND  (Minus. Tol  = 0.0)); 

MEMBER(Size_Dimension  , 1 , # ) OR  MEMBERCLocation.Dimension , 1 ,#) 

OR  HEMBERCAngle.Dimension  , 1 ,#)  ; 

END. ENTITY; 


Attribute  De^nitionsj 
Plus  Tol 

The  absolute  value  of  the  tolerance  that  is  added  to  the  nominal  dimension  value  to  establish 
the  maximum  allowable  deviation  of  the  toleranced  entity  from  the  nominal. 

Minus -Tol 

The  absolute  value  of  the  tolerance  that  is  subtracted  from  the  nominal  dimension  value  to 
establish  the  minimum  allowable  deviation  of  the  toleranced  entity  from  the  nominal. 

Propositions: 

Each  Coordinate-Tolerance  Jlange(401) 

• is  a Shape -Tolerance(400). 

• may  tolerance  0,  1 or  more  Location  Dimensions  (602). 

• may  tolerance  0,  1 or  more  Angle  Dimension  (603). 

• may  tolerance  0,  1)  or  more  Size  Dimension  (601). 

• must  tolerance  a Location,  Angle  or  Size  Dimension. 
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Entity  Name;  Geometric. Tolerance 
Entity  Number;  402 

A Geometric-Tolerance  is  a class  of  entities.  Geometric  tolerances  as  defined  by  ANSI  Y14.5M 
1982  tolerance  the  deviation  of  form,  orientation,  location,  and  runout,  of  a produced  feature  from 
its  design  nominal. 

EXPRESS  Definition: 

ENTITY  Geomtric.Tolerance  SUBTYPE  OF  (Shape.Tolerance) ; 

END.ENTITY; 


Propositions: 

Each  Geometric-Tolerance(402) 

• is  a Shape-Tolerance(400). 

• may  be  an  Angularity(406)  tolerance, 
may  be  a Circular_Runout(407)  tolerance, 
may  be  a Circularity(408)  tolerance, 
may  be  a Concentricity(409)  tolerance, 
may  be  a Cylindricity(410)  tolerance, 
may  be  a Flatness(411)  tolerance. 

may  be  a Parallelism(412)  tolerance, 
may  be  a Perpendicularity(413)  tolerance, 
may  be  a Position(414)  tolerance, 
may  be  a ProfLle-Line(415)  tolerance, 
may  be  a Profile-Surface(416)  tolerance, 
may  be  a Straightness(417)  tolerance, 
may  be  a Total-Runout (4 18)  tolerance. 

• must  be  one  of  the  listed  tolerances  (406-418). 
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Fig^l^e  D-17:  COORDINATE  RANGE  IDEFlX  Diagram 
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Entity  Name;  Angularity  Tolerance 
Entity  Number;  406 

Angularity  is  the  condition  of  a surface  or  axis  at  a specified  angle  (other  than  90  degrees)  fmm 
a datum  plane  or  axis.  An  Angularity  tolerance  specifies  a tolerance  zone  defined  by  two  parallel 
planes  at  the  specified  basic  angle  from  the  datum  plane  or  axis  witlun  whtch  the  surface  or  axis 
of  the  considered  feature  must  lie. 


See  ANSI  Y14.5M  1982,  page  106,  section  6.6.2 
See  ISO  1101,  pages  18-19,  section  5.9 


EXPRESS  Definition: 


(* 


ENTITY  Angularity  SUBTYPE 
Tol.Ent  : 

Tolerance  ; 

Material.condit ion  : 
Projection  : 

Primary.datum  : 

Secondary.datmn  : 
Tertiary.datmn  : 
WHERE 


OF  (Geometric.Tolerance) ; 

SET  OF  SELECT  (Seam, Area, 
Feature.of .Size) ; 

Number ; 

Tol.MLSN; 

Optional  Projected.Tolerance.Zone ; 
Conditioned .datum ; 

Optional  Conditioned.datum : 
Optional  Conditioned.datum; 


Tol.Ent  <>  []  ; 

Tolerance  > 0; 

IF  SYMMETRICCToleranced. Entity)  THEN 
Material. Condition  = M OR 

Material.Condition  = L OR 

Material.Condition  = S; 

ELSE 


Material.Condition  = N;  •) 

END. ENTITY; 


Default  Condition 


A ttribute  Definitions: 

Toleranced  Entity 

A set  of  entities  to  which  the  tolerance  applies. 

Tolerance 

The  allowable  deviation  of  the  measured  dimensional  value  from  the  design  nominal. 
Material-condition 

An  enumerated  list  that  indicates  the  material  condition  at  which  the  tolerance  applies: 
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Figure  D-18:  GEOMETRIC  TOLERANCE  IDEFIX  Diagram 
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M - maximum  material  condition;  L - least  material  condition,  or  S - regardless  of  feature 
size;  N - Not  Applicable 

Projection 

A Projected. Tolerance  Zone  which  specifies  the  additional  height  and  direction  of  the  pro- 
jected tolerance  zone  outside  the  feature  boundary. 

Note:  Must  be  parallel  to  the  toleranced  features.  Length  of  vector  determines  the  extent 
of  the  zone. 

Primary-datum 

A conditioned  datum  entity  from  which  the  dimension  is  measured.  This  datum  is  the  most 
important  datum  relative  to  the  tolerance. 

Secondary -datum 

A conditioned  datum  entity  which  is  the  second  most  important  datum  relative  to  the  toler- 
ance. 

Tertiary. datum 

A conditioned  datum  entity  which  is  the  third  most  important  datum  relative  to  the  tolerance. 
With  the  primary  and  secondary  datums,  it  establishes  a datum  reference  frame  that  exactly 
locates  the  toleranced  feature. 

Propositions: 

Each  Angularity(406)  tolerance 

• is  a Geometric-Tolerance(402). 

• has  a projected  tolerance  zone  defined  by  0 or  1 Projected. Tolerance-Zone(  102). 

• has  a primary  datum  of  exactly  one  Conditioned  JDatum(302). 

• may  have  a secondary  datum  of  one  Conditioned  JDatum(302). 

• may  have  a tertiary  datum  of  one  Conditioned_Datum(302). 

• tolerances  1 or  more  Seam(INT-14),  Area(INT-8),  or  Feature.of.Size(306). 
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Entity  Name;  Circular  Runout  Tolerance 

Entity  Number:  407 

Circular  runout  tolerance  defines  the  maximum  allowable  deviation  of  position  of  a point  on 
the  toleranced  feature  during  one  complete  revolution  of  the  feature  about  the  datum  axis,  with- 
out relative  axial  displacement  of  the  measuring  position.  Where  applied  to  surfaces  constructed 
around  a datum  axis,  it  is  used  to  to  control  the  cumulative  variations  of  circularity  and  coaxialitv. 
Where  applied  to  surfaces  constructed  at  right  angles  to  the  datum  axis,  circular  runout  controls 
circular  elements  of  a planar  surface. 

See  ANSI  Y14  5M  1982,  page  109,  section  6. 7.2.1 
See  ISO  1101,  page  22-23,  section  5.12 

EXPRESS  Definition: 

ENTITY  Circular.Runout  SUBTYPE  OF  (Geometric.Tolerance ) : 

Tol.Ent  : SET  OF  SELECTf Area , Feature.of .Size ) ; 

Tolerance  : Number: 

Primary.datum  ; Unconditioned.Datum ; 

Co-primary.datum  ; Optional  Unconditioned.Datum ; 

WHERE 

Tol.Ent  <>  []  : 

Tolerance  > 0; 

(*  For  each  member  in  Toleranced.Entity 

((CIRCULAR(member)  = TRUE)  OR 
(DISK(member)  = TRUE));  *) 

END. ENTITY; 


Attribute  Definitions; 

Toleranced  J)ntity 

A set  of  entities  to  which  the  toleramce  applies. 

Tolerance 

The  allowable  deviation  of  the  measured  dimensional  value  from  the  design  nominal 

Primary-datum:  A datum  entity  from  which  the  dimension  is  measured.  The  primary  datum  is 
the  most  importzmt  datum  relative  to  the  tolerance. 

Co-primary.datum 

An  additional  datum  entity  which  establishes  an  axis  with  the  primary  datum. 
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Constraint  Definitions: 

For  each  member  in  Toleranced  Entity 

((CIRCULAR(member)  = TRUE)  OR  (DISK(member)  = TRUE)) 

CIRCULAR  is  a function  which  returns  the  value  TRUE  if  cross  sections  of  the  input  entity  (or 
each  member  of  a list  of  entities)  in  a plane  normal  to  the  axis  are  circular.  DISK  is  a function 
which  returns  a value  TRUE  of  the  input  entity  (or  each  member  of  a list  of  entities)  is  normal  to 
the  axis  of  rotation,  planar,  and  has  a circular  boundary. 

Propositions; 

Each  Circular -Runout  (40  7)  tolerance 

• is  a Geometric-Tolerance(402). 

• has  a datum,  of  exactly  one  Unconditioned_Datum(310). 

• may  have  a co-datum  of  one  Unconditioned-Datum(310). 

• tolerances  1 or  more  Seam(INT- 14),  Area(INT-8)  or  Feature-of-Size(306). 
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Entity  Name;  Circularity  Tolerance 
Entity  Number;  408 

Circularity  is  a condition  of  a surface  of  revolution  such  that  all  points  of  the  surface  intersected 
by  a plane  perpendicular  to  the  axis  or  center  point  are  equidistant  from  the  intersection  point  of 
the  plane  and  the  axis  or  center  point.  A Circularity  tolerance  defines  the  distance  between  two 
concentric  circles  within  which  the  coordinates  of  the  toleranced  feature  must  Lie.  These  circles  are 
perpendicular  to  and  centered  on  the  axis  of  the  toleranced  feature. 

See  ANSI  Y14.5M  1982,  page  95,  section  6.4.3 
See  ISO  1101,  page  14,  section  5.3 

EXPRESS  Definition: 

ENTITY  Circularity  SUBTYPE  OF  (Geometric.Tolerance) ; 

Tol_Ent  : SET  OF  SELECT  (Seam, Area, Feature.of .Size) ; 

Tolerance  : Number; 

WHERE 

Tol.Ent  <>  []  ; 

Tolerance  > 0; 

(* *  CIRCULARCTol.Ent)  = TRUE;  *) 

END. ENTITY; 


Attribute  Definitions: 

Toleranced  Jlntity 

A set  of  entities  to  which  the  tolerance  applies. 

Tolerance 

The  allowable  deviation  of  the  measured  dimensional  value  from  the  design  nominal. 

Con straint  Definitions; 

CIRCULAR(Tol_Ent)  = TRUE; 

The  asserts  that  the  entity(ies)  to  which  this  tolerance  applies  must  circular  (see  Circular  Runout 
for  definition  of  function). 

Propositions: 

Each  Circularity(408)  tolerance 

• is  a Geometric-Tolerance(402). 

• tolerances  1 or  more  Seam(INT-14),  Area(INT-8),  Feature-of.Size(306); 
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Entity  Name;  Concentricity  Tolerance 
Entity  Number;  409 

Concentricity  tolerance  specifies  the  diameter  of  cylinder  centered  on  a datum  point  or  axis 
within  which  the  center  or  axis  of  the  toleranced  circular  or  cylindrical  feature  must  lie.  The  spec- 
ified tolerance  and  datum  reference  apply  only  on  a Regardless-of-Feature-Size  basis. 

See  ANSI  Y14.5M  1982,  page  84,  section  5.11.3 
See  ISO  1101,  page  21,  section  5.11.1 


EXPRESS  Definition; 


(* 


ENTITY  Concentricity  SUBTYPE  OF  (Geometric.Tolerance) ; 


Tol.Ent 
Tolerance 
Cylindrical. zone 
Primary.datum 
Co -primary .datum 
WHERE 


SET  OF  SELECT  (Area, Feature. of .Size) ; 
Number ; 

Logical : 

Unconditioned.Datum : 

Optional  Unconditioned  Datum; 


Tol.Ent  <>  []  : 

Tolernace  > 0; 

CIRCULAR(Tol.Ent)  = TRUE;  * ) 
END. ENTITY; 


Attribute  Definitions; 

Toleranced -Entity 

A set  of  entities  to  which  the  tolerance  applies. 

Tolerance 

The  allowable  deviation  of  the  measured  dimensional  value  from  the  design  nominal. 
Cylindricaljone 

A boolean  (true/faJse)  flag  that  indicates  that  the  tolerance  value  is  the  diameter  of  a cylin- 
dricsd  zone  within  which  the  axis  or  line  must  lie  If  false,  the  zone  is  parallelepipedic  or  the 
space  between  two  paraUel  lines  or  planes. 

Primary.datum 

A datum  entity  from  which  the  dimension  is  measured.  The  primary  datum  is  the  most 
important  datum  relative  to  the  tolerance. 

Co-primary-datum 

An  additional  datum  entity  which  establishes  an  axis  with  the  primary  datum. 
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Figure  D-21:  CIRCULARITY  IDEFIX  Diagram 


161 


ISO  TC18-1  5C4  WGl 


A N N E X D U cl o b e r 3 1 , 1 V ' 8 

(Draft  Proposal 

SECTION  3:  SHAPE  VARIATION  TOLERANCES 


Constraint  Description; 

CIRCULAR(Tol.Ent)  = TRUE; 

Asserts  that  the  entity(ies)  to  which  this  tolerance  applies  must  be  circular  (see  Circular  Runout 
for  definition  of  function) 

Propositions: 

Each  Concentricity(409)  tolerance 

• is  a Geometric-Tolerance(402). 

• has  a datum  of  one  Unconditioned  J3atum(310). 

• has  a co-datum  of  0 or  1 Unconditioned  Datum(310). 

• tolerances  1 or  more  Seam(INT-14),  Area(INT-8),  or  Feature  of-Size(306). 
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Entity  Name;  Cylindricity  Tolerance 
Entity  Number;  410 

Cylindricity  tolerance  defines  the  distance  between  two  coaxial  cylinders  within  which  the  toler- 
anced  cylindrical  feature  must  lie.  Unlike  circularity,  the  tolerance  applies  simultaneously  to  both 
circular  and  longitudinal  elements  of  the  surface 

See  ANSI  Y14.5M  1982,  page  96,  section  6.4.4. 

See  ISO  1101,  page  14,  section  5.4 

EXPRESS  Definition: 

ENTITY  Cylindricity  SUBTYPE  OF  (Geometric.Tolerance) ; 

Tol_Ent  : SET  OF  SELECT  (Area, Feature_of .Size) ; 

Tolerance  : Number; 

WHERE 

Tol.Ent  <>  []  ; 

Tolerance  > 0: 

(* *  CYLINDRICAL(Tol.Ent)  = TRUE;  *) 

END. ENTITY: 


Attribute  Definitions: 

Toleranced  Entity 

A set  of  entities  to  which  the  tolerance  applies. 

Tolerance 

The  allowable  deviation  of  the  measured  dimensional  value  from  the  design  nominal. 

Constraint  Definitions: 

CYLINDRICALCTol.Ent)  = TRUE; 


The  CYLINDRICAL  function  returns  a value  TRUE  if  the  input  entity  (or  each  member  from  a 
list  of  entities)  is  cylindrical. 

Propositions; 

Each  Cylindricity(410)  tolerance 

• is  a Geometric-Tolerance(402). 

• tolerances  1 or  more  Area(INT-8)  or  Feature-of-Size(306). 
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Figure  D-22:  CONCENTRICITY  IDEFIX  Diagram 
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Entity  Name;  Flatness  Tolerance 
Entity  Number;  411 

Flatness  tolerance  defines  the  distance  between  two  parallel  planes  between  which  the  toler- 
anced  surface  must  lie.  The  tolerance  may  be  applied  on  a unit  basis  as  a means  of  preventing 
abrupt  surface  variation  within  a small  area  of  the  feature. 

See  ANSI  Y14.5M  1982,  page  94,  section  6.4.2 
See  ISO  1101,  page  13,  section  5.2 

EXPRESS  Definition: 

ENTITY  Flatness  SUBTYPE  OF  (Geometric_Tolerance) ; 

Tol.Ent  : SET  OF  Area; 

Tolerance  : Number; 

Per.unit.square  : Optional  Number: 

WHERE 

(Per_unit_Square  > 0.0); 

Tol.Ent  <>  []  ; 

Tolerance  > 0; 

(*  PLANAR(Tol_Ent)  = TRUE;  *) 

END.ENTITY; 


Attribute  Definitions: 

Toleranced-Entity 

A set  of  entities  to  which  the  tolerance  applies. 

Tolerance 

The  aUowable  deviation  of  the  measured  dimensional  value  from  the  design  nominal. 

Per  unit  square 

Specifies  the  side  of  square  region  on  the  Toleranced-Entity  over  which  the  tolerance  value 
applies.  Used  to  prevent  abrupt  surface  variations  in  a relatively  small  area  of  the  feature. 

Constraint  Definitions: 

PLANAR(Tol.Ent)  = TRUE 


The  PLANAR  function  returns  a value  TRUE  if  the  input  entity  (or  each  member  from,  a list  of 
entities)  is  planar. 
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Propositions: 

Each  Flatness(411)  tolerance 

• is  a Geometnc-Tolerance(402). 

• tolerances  1 or  more  Area(INT-8). 
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Figure  D-24:  FLATNESS  IDEFIX  Diagram 
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Entity  Name;  Parallelism  Tolerance 

Entity  Number:  412 

Parellelism  is  the  condition  of  a surface  equidistant  at  all  points  from  a datum  plane  or  an 
axis  equidistant  along  the  length  from  the  datum  axis.  Parallelism  tolerance  specifies  the  distance 
between  two  planes  or  lines  parallel  to  a datum  plane  or  axis  within  which  the  line  elements  of 
the  surface  or  axis  of  the  considered  feature  must  Lie,  or  a cylindrical  tolerance  zone  whose  axis  is 
parallel  to  the  datum  axis,  within  which  the  axis  of  the  considered  feature  must  lie.  The  allowable 
feature  position  zone  may  be  cyLindrical(fig  45),  parallelepipedic  (fig  51)  or  planar  (fig  47,54)  for 
line  features  and  is  similar  to  a flatness  tolerance  zone  for  surface  features  (fig  57,60).  These  figure 
references  are  to  the  ISO  1101  standard. 


See  ANSI  Y14.5M  1982,  page  106,  section  6.6.3 


See  ISO  1101,  page  15-17,  section  5.7 

EXPRESS  Definition: 

ENTITY  Parallelism  SUBTYPE 
Tol.Ent  : 

Tolerance  : 

Material_condition  ; 
Cylindrical_2one  : 
Projection  : 

Primary.datum  : 

WHERE 

Tol_Ent  <>  []  : 
Tolerance  > 0; 

(*  IF  SYMMETRIC(Tol_Ent) 

Material. Condition 
Material.Condition 
Material.Condition 
ELSE 

Material.Condition 

END.ENTITY: 


OF  (Geometric.Toleramce) ; 

SET  OF  SELECT (Seam , Area , 

Feature.of .Size) ; 

Number ; 

Tol.MLSN; 

Logical : 

Optional  Projected.Toleramce.Zone; 
Conditioned.datum; 


THEN 

® M OR 
= L OR 

s S;  — Default  Condition 

= N;  *) 


Attribute  Definitions; 

Toleranced-Entity  A set  of  entities  to  which  the  tolerance  applies. 

Tolerance 

The  allowable  deviation  of  the  measured  dimensional  value  from  the  design  nominal. 
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Material-Condition 

An  enumerated  List  that  indicates  the  material  condition  at  which  the  tolerance  applies' 

M - maximum  material  condition;  L - least  material  condition;  S - regardless  of  feature  size; 

N • Not  applicable. 

Cylindrical-zone  I 

A boolean  (true/false)  flag  that  indicates  that  the  tolerance  value  is  the  diameter  of  a cylin-  I 

drical  zone  within  which  the  axis  or  line  must  lie.  If  false,  the  zone  is  parallelepipedic  or  the  { 

space  between  two  parallel  lines  or  planes.  i 

Projection 

A point,  a direction,  and  an  extent  which  specify  the  additional  height  and  direction  of  the 
projected  tolerance  zone  outside  the  feature  boundary. 

Note:  Must  be  parallel  to  the  toleranced  features. 

Primary-datum 

A conditioned  datum  entity  from  which  the  dimension  is  measured 

Propositions: 

Each  Parallelism(412)  tolerance 

• is  a Geometric-Tolerance(402). 

• has  exactly  one  datum  of  Conditioned_Datum(302). 

• has  a project  tolerance  zone  defined  by  0 or  1 Projected  Tolerance .Zone(102). 

• tolerances  1 or  more  Seam(INT- 14),  Area(INT-8),  or  Feature-of  Size(306). 
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Entity  Name;  Perpendicularity  Tolerance 

Entity  Number:  413 

Perpendicularity  tolerance  defines  the  allowable  linear  deviation  from  a true  right  angle  of  line 
or  surface  features  with  respect  to  line  or  surface  datums.  Several  interpretations  of  the  exact 
tolerance  zone  are  possible  for  line  features  with  respect  to  surface  datums. 

See  figures  65,67  and  69  in  ISO  1101,  page  17. 

See  ANSI  Y14.5M  1982,  page  106,  section  6.6.4 
See  ISO  1101,  page  17-18,  section  5.8 


EXPRESS  Definition: 


ENTITY  Perpendicularity 
Tol.Ent 

Tolerance 

Material.condition 
Cylindrical .zone 
Projection 
Primary.datum 
Secondary .datum 


SUBTYPE  OF  (Geometric. Tolerance) ; 

: SET  OF  SELECT(Seam , Area , 

Feature. of .Size) ; 

: Number: 

: Tol.MLSN; 

: Logical; 

: Optional  Projected.Tolerance.Zone ; 
: Conditioned. datum; 

: Optional  Conditioned. datum ; 


WHERE 


Tol.Ent  <>  []  : 

Tolerance  > 0; 

IF  SYMMETRICCToleranced. Entity)  THEN 
Material. Condition  = M OR 

Material.Condition  = L OR 

Material. Condition  = S;  --  Default  Condition 


ELSE 

Material.Condition  = N;  *) 

END. ENTITY; 


Attribute  Definitions: 

Toleranced-Entity 

A set  of  entities  to  which  the  tolerance  applies. 

Tolerance 

The  allowable  deviation  of  the  measured  dimensional  value  from  the  design  nominal. 
Material-condition 

An  enumerated  list  that  indicates  the  material  condition  at  which  the  tolerance  appbes: 
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M - maximum  material  condition;  L - least  material  condition-  S - regardless  of  feature  s;:e; 
N - Not  Applicable. 

Cylindrical -zone 

A boolean  (true/false)  flag  that  indicates  that  the  tolerance  value  is  the  diameter  of  a cylin- 
drical zone  within  which  the  axis  or  Line  must  lie.  If  false,  the  zone  is  parallelepipedic  or  the 
space  between  two  parallel  lines  or  planes 

Projection 

A point,  a direction  and  an  extent  which  specify  the  additional  height  and  direction  of  the 
projected  tolerance  zone  outside  the  feature  boundary. 

Note:  Must  be  parallel  to  the  toleranced  features.  Length  of  vector  determines  the  extent 
of  the  zone. 

Primary-datum 

A Conditioned-Datum  entity  from  which  the  dimension  is  measured.  This  primary  datum  is 
the  most  important  datum  relative  to  the  tolerance. 

Secondary  datum 

A conditioned-Datum  entity  which  , the  second  most  important  datum  relative  to  the  toler- 
ance. 

Propositions: 

Each  Perpendicularity(413)  tolerance 

• is  a Geometric-Tolerance(402). 

• has  Primary  datum  of  exactly  one  Conditioned  Datum(302). 

• may  have  a secondary  datum  of  one  Conditioned_Datum(302). 

• has  a projected  tolerance  zone  defined  by  0 or  i Projected.Tolerance-Zone(  102). 

• tolerances  1 or  more  Seam(INT-14),  Area(INT-8),  or  Feature-of-Size(306). 
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Entity  Name;  Position  Tolerance 

Entity  Number;  414 

Position  tolerance  defines  the  allowable  deviation  of  position  of  the  center  point  axis  or  center 
plane  of  a feature  of  size.  A center  point  tolerance  defines  the  diameter  of  a spherical  or  circular 
zone,  an  axis  tolerance  defines  the  measure  of  a cylindrical,  parallelepipedic  or  planar  zone  and 
a center  plane  tolerance  defines  a zone  specified  by  the  distance  between  two  bounding  parallel 
planes.  Each  zone  is  considered  to  contain  the  true  position  of  the  toleranced  feature. 


See  ANSI  Y14.5M  1982,  page  53-89,  section  5.2 
See  ISO  1101,  page  19-20,  section  5.10 


EXPRESS  Definition: 


ENTITY  Position  SUBTYPE  OF  (Geometric  Tolerance) ; 


Tol.Ent 
Tolerance 

Material. condition 
Cylindrical .zone 
Projection 
Primary. datum 
Secondary. datum 
Tertiary. datum 
WHERE 

Tol.Ent  <>  []  : 

Tolerance  > 0; 

IF  SYMMETRICCToleranced. Entity)  THEN 
Material. Condition  = M OR 

Material. Condition  = L OR 

Material.Condition  = S; 

ELSE 

Material.Condition  = N;  *) 

END.ENTITY; 


SET  OF  Feature.of .Size ; 

Number ; 

Tol.MLSN; 

Logical ; 

Optional  Projected. Tolerance. Zone ; 
Conditioned. datum ; 

Optional  Conditioned. datum ; 
Optional  Conditioned. datum ; 


■-  Default  Condition 


Attribute  Definitions; 

Toleranced-Entity 

A set  of  entities  to  which  the  tolerance  applies. 

Tolereuice 

The  allowable  deviation  of  the  measured  dimensional  value  from  the  design  nominal. 
Material-condition 

An  enumerated  list  that  indicates  the  material  condition  at  which  the  tolerance  applies: 
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Figure  D-26;  PERPENDICULARITY  IDEFIX  Diagram 
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M - maximum  material  condition;  L - least  material  condition;  S - regardless  of  feature  sire; 
N - not  applicable. 

Cylindrical -Zone 

A boolean  (true/false)  flag  that  indicates  that  the  tolerance  value  is  the  diameter  of  a cylin- 
drical zone  within  which  the  axis  or  line  must  lie.  If  false,  the  zone  is  parallelepipedic  or  the 
space  between  two  parallel  lines  or  planes. 

Projection 

A point,  a direction  and  an  extent  which  specify  the  additional  height  and  direction  of  the 
Projected. Tolerance-Zone  outside  the  feature  boundary. 

Note:  Must  be  parallel  to  the  toleranced  features. 

Primary-datum 

A Conditioned-Datum  entity  from  which  the  dimension  is  measured.  This  primary  datum  is 
the  most  important  datum  relative  to  the  tolerance. 

Secondary.dat  um 

A conditioned. Datum  entity  which  is  the  second  most  important  datum  relative  to  the  toler- 
ance 

Tertiary-datum 

A conditioned  datum  entity  which  is  the  tlurd  most  important  datum  relative  to  the  tolerance. 
With  the  primary  and  secondary  datums,  it  establishes  a datum  reference  frame  that  exactly 
located  the  toleranced  feature. 

Propositions; 

Each  Position(414)  tolerance 

• is  a Geometric  Tolerance(402) 

• has  a primary  datum  of  exactly  one  Conditioned-Datum(302). 

• may  have  a secondary  datum  of  one  Conditioned_Datum(302). 

• may  have  a tertiary  datum  of  one  Conditioned-Datum(302). 

• has  a projected  tolerance  zone  defined  by  0 or  1 Projected. Tolerance-Zone(  102). 

• tolerances  1 or  more  Feature  of-Size(306). 
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Entity  Name;  Profile  of  a Line  Tolerance 

Entity  Number:  415 

Profile  of  a line  tolerance  specifies  the  diameter  of  a circle  which  when  its  center  or  one  tangent 
moves  along  the  design  nomincd  curve  feature,  sweeps  the  region  in  which  the  feature  must  lie.  The 
tolerance  is  two  dimensional  and  applies  normal  (perpendicular)  to  the  true  profile  at  all  points 
Where  a sharp  corner  is  included,  the  tolerance  zone  extends  to  the  intersection  of  the  boundary 
lines. 

See  ANSI  Y14.5M  1982,  page  97-104,  section  6.5.1 
See  ISO  1101,  page  14,  section  5.5 


EXPRESS  Definition; 


(* 


ENTITY  Profile.Line  SUBTYPE  OF  (Geometric.Tolerance) 


Tol.Ent 
Tolerance 
Directrix 
Application 
Primary.datum 
Secondary .datum 
Tertiary.datum 
WHERE 


SET  OF  SELECT  (Seam,  Area) 
Number : 

Optional  Direction; 
Tol.IBO: 

Optional  Conditioned.datum 
Optional  Conditioned.datum 
Optional  Conditioned.datum 


Tol.Ent  <>  []  : 

Tolerance  > 0; 

NOT  ((Tol.Ent  = Edge)  AND  NOT  PLANAR(Tol_Ent ) ) ; 
IF  (Tol.Ent  = Edge)  THEN  Directrix  = NUL ; *) 

END. ENTITY: 


Attribute  Definitions: 

TolerancedJEntity 

A set  of  entities  to  which  the  the  tolerance  applies. 

Tolerance 

The  allowable  deviation  of  the  measured  dimensional  value  from  the  design  nominal. 
Application 

An  enumerated  list  that  specifies  the  tolerance  application  to  be  I - inside,  B - bilateral, 
0 - Outside. 

Primary-datum 

A Conditioned-Datum  entity  from  which  the  dimension  is  measured.  This  primary  datum  is 
the  most  important  datum  relative  to  the  tolerance. 
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Secondary  .datum 

A conditioned JDatum  entity  which  is  the  second  most  important  datum  relative  to  the  toler- 
ance. 

Tertiary-datum 

A conditioned  datum  entity  which  is  the  third  most  important  datum  relative  to  the  tolerance. 
With  the  primary  and  secondary  datums,  it  establishes  a datum  reference  frame  that  exactly 
located  the  toleranced  feature. 

Directrix 

Cross  sections  of  the  toleranced  face  taken  in  planes  normal  to  the  directix  establish  the  line 
profile  that  is  toleranced.  The  directrix  is  required  only  if  a datum  is  not  included  in  the  line 
tolerance  entity. 

Constraint  Definitions; 

(Tol.Ent  = Edge)  AND  PLANARCTol.Ent ) ) ; 

IF  (Tol.Ent  = Edge)  THEN  Directrix  = NULL: 


This  clause  asserts  that  if  the  entity  to  which  the  tolerance  applies  is  an  Seam,  the  underlying  curve 
of  the  Seam  must  be  defined  within  a plane,  (see  Flatness  for  definition  of  PLANAR).  It  further 
asserts  that  the  Directrix  is  meaningless  and  should  be  null  if  the  Tol_Ent  is  an  Seam  (A  value  for 
the  Directrix  may  be  assigned  if  there  are  entities  in  the  list  which  are  Areas). 

Propositions: 

Each  Profile  of  a-Line(415)  tolerance 

• is  a Geometric-Tolerance(402). 

• may  have  a primary  datum  of  one  Conditioned_Datum(302). 

• may  have  a secondary  datum  of  one  Conditioned  J!)atum(302). 

• may  have  a tertiary  datum  of  one  Conditioned  JDatum(302). 

• may  have  profile  determined  in  planes  normal  to  one  Direction(GE0-14). 

• tolerances  1 or  more  Seam(INT-14)  or  Area(INT-8). 
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Entity  Name:  Profile  of  a Surface  Tolerance 

Entity  Number;  416 

A profile  of  a surface  tolerance  specifies  the  distance  between  two  “ball-offset”  surfaces  located 
equally  on  either  side,  or  totally  on  one  side  of  the  design  nominal  feature.  The  toleranced  feature 
must  lie  between  these  surfaces.  The  tolerance  is  three-dimensional  and  applies  normal  (perpendic- 
ular) to  the  true  profile  at  all  points.  Where  a sharp  corner  is  included,  the  tolerance  zone  extends 
to  the  intersection  of  the  boundary. 

See  ANSI  Y14.5M  1982,  page  97-104,  section  6.5.1 
See  ISO  1101,  page  14,  section  5.5 


EXPRESS  Definition: 

ENTITY  Profile.Surfac 
Tol.Ent 
Tolerance 
Default 
Application 
Primary.datum 
Secondary .datum 
Tertiary.datum 

(*  WHERE 

Tolerance  >=  0; 
EMPTYCToleranced 
UNIQUECDefault  = 
END. ENTITY; 


> SUBTYPE  OF  (Geometric. Tolerance ) : 
; SET  OF  Area; 

: Number; 

: Logical; 

: Tol.IBO; 

: Optional  Conditioned.datum ; 

: Optional  Conditioned.datum; 

: Optional  Conditioned.datum; 

.Entity)  = Default; 

TRUE);  *) 


Attribute  Definitions: 

Toleranced  J)ntity 

A set  of  entities  to  which  the  tolerance  applies. 

Tolerance 

The  allowable  deviation  of  the  measured  dimensional  value  from  the  design  nominal. 

Default 

A Boolean  flag  used  to  denote  the  instance  of  the  Profile-Surface. Tolerance  that  is  used  as 
the  default  tolerance  within  the  Product  Model.  Only  one  instance  of  this  entity  may  have 
this  attribute  set  to  TRUE,  and  this  one  may  not  reference  any  toleranced  entity  (hence,  a 
cardinality  of  0 is  allowed  for  this  entity). 
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Application 

An  enumerated  List  that  specifies  the  tolerance  application  to  be  I - inside,  B - bilateral 
0 - Outside. 

Primary  datum 

A Conditioned-Datum  entity  from  which  the  dimension  is  measured.  Tliis  primary  datum  is 
the  most  important  datum  relative  to  the  tolerance. 

Secondary  -datum 

A Conditioned-Datum  entity  which  is  the  second  most  important  datum  relative  to  the  toler- 
ance. 

Tertiary. datum 

A conditioned  datum  entity  which  is  the  third  most  important  datum  relative  to  the  tolerance. 
With  the  primary  and  secondary  datums,  it  establishes  a datum  reference  frame  that  exactly 
located  the  toleranced  feature. 

C o n s t r ai at  D efi nUi pnj : 

EMPTY(Tol.Ent)  = Default; 

UNIQUE(Default  = TRUE) ; 


This  constraint  asserts  that  if  the  Tol.Ent  set  is  EMPTY,  then  the  Default  flag  must  be  TRUE. 
In  addition,  the  instance  of  the  entity  where  this  condition  is  true  must  be  UNIQUE  (i.e.  there  is 
only  one  entity  which  has  a default  flag  set  to  TRUE.) 

Propositions: 

Each  Profile  of  a Surface(416)  tolerance 

• is  a Geometric.Tolerance(402). 

• may  have  a primary  datum  of  one  Conditioned-Datum(302). 

• may  have  a secondtiry  datum  of  one  Conditioned_Datum(302). 

• .lay  have  a tertiary  datum  of  one  Conditioned-Datum(302). 

• tolerances  1 or  more  Area  (INT-8). 
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Entity  Name;  Straightness  Tolerance 

Entity  Number;  417 

Straightness  tolerance  defines  the  allowable  deviation  of  a line  or  of  line  elements  of  a surface 
feature.  The  tolerance  zones  for  Line  features  are  cylindrical,  paraUelepipedic  and  parallel  planes. 
Straightness  tolerance  for  surface  features  specify  the  distance  between  two  parallel  lines  within 
which  a linear  element  of  the  surface  in  a specified  direction,  must  Lie,  The  linear  elements  is  a 
cross  section  of  the  surface  in  a plane  parallel  to  the  direction  vector  and  normal  to  the  surface 

See  figures  27,29  and  31  in  the  ISO  1101  standard,  page  17. 

See  ANSI  Y14.5M  1982,  page  91-94,  section  6.4.1 
See  ISO  1101,  page  13,  section  5.1 


EXPRESS  Definition: 


ENTITY  Straightness  SUBTYPE  OF  (Geometric.Tolerance) ; 


Tol.Ent 

Tolerance 

Direction 

Material .condition 
Cylindrical .zone 
Per. unit. length 
WHERE 


SET  OF  SELECT (Seam , Area , 
Feature. of .Size) ; 
Number ; 

Optional  Direction; 
Tol.MLSN: 

Logical ; 

Number ; 


(per. unit. length  > 0.0); 
Tol.Ent  <>  []  ; 

Tolerance  > 0; 


(*  IF  SYHMETRIC(Tol.Ent)  THEN 
Material. Condition  = M 
Material.Condition  = L 
Material.Condition  = S; 


OR 

OR 

--  Default  Condition 


ELSE 

Material.Condition  = N; 

IF  (Tol.Ent  <>  Edge)  THEN  LINEAR. SECTI0NS(Direction , Tol.Ent); 
IF  (Tol.Ent  = Edge)  THEN  Direction  = NULL:  *) 

END.ENTITY: 


Attn  but  e Definitions: 

Toleranced  J)ntity 

A set  of  entities  to  which  the  tolerance  applies. 

Tolerance 

The  allowable  deviation  of  the  measured  dimensional  value  from  the  design  nominal. 
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CONDITIONED  DATUH/302 


IS  S LCONDARY  DATUM  OF 


IS  TERTIARY 

DATUM  or 


AREA/INTg 


J 

-f 

TOLERANCES 

C>  i ^ 

!>  ( 1 ) 

PSRF-TOLj 

•ENT/516 

J 

( 1 ) 


THERE  MAY  BE  ONE  INSTANCE  01 
PROFILE. SURFACE  ENTITY  UITH 
THE  ATTRIBUTE  ’DEFAULT*  SET 
•TRUE*.  this  INSTANCE  IS  T! 
ONLY  ONE  WHICH  DOES  NOT  APPl 
TO  A PSRF-TOL-ENT. 


Figure  D-29:  PROFILE  OF  A SURFACE  IDEFIX  Diagram 
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Direction 

A direction  that  specifies  the  straightness  tolerance  for  linear  surface  elements  R.equired 
when  the  toleranced  entity  is  a surface.  It  must  be  parallel  to  the  surface 

Material  condition 

An  enumerated  list  that  indicates  the  material  condition  at  which  the  tolerance  applies; 

M - maximum  material  condition;  L - least  material  condition:  S - regardless  of  feature  size; 
N - Not  applicable. 

Cylindrical  zone 

A boolean  (true/false)  flag  that  indicates  that  the  tolerance  value  is  the  diameter  of  a cylin- 
drical zone  within  which  the  axis  or  line  must  lie.  If  false,  the  zone  is  paraUelepipedic  or  the 
space  between  two  parallel  lines  or  planes. 

Per.unit  Jength 

Specifies  the  linear  distance  within  which  the  tolerance  value  applies.  Used  to  prevent  abrupt 
changes  in  the  direction  of  the  toleranced  entity. 

Constraint  Definitions; 

IF  (Tol.Ent  <>  Edge)  THEN  LINEAR.SECTIONS (Direction , Tol.Ent); 

IF  (Tol.Ent  = Edge)  THEN  Direction  = NULL: *  *) 


LINEAR  SECTIONS  is  a function  which  returns  a value  TRUE  if  all  cross  sections  of  the  toleranced 
surface  (or  members  of  a list  of  entities)  taken  in  planes  tangent  to  the  direction  are  straight  lines. 
If  the  Tol_Ent  contains  a Seam,  then  the  Direction  does  not  apply.  If  the  Toleranced.Entity  list 
contains  only  Seams,  then  Direction  must  be  Null. 

Propositions: 

Each  Straightness(417)  tolerance 

• is  a Geometric-Tolerance(402). 

• may  have  a direction  of  application  defined  by  one  Direction(GE0-14). 

• tolerances  1 or  more  Seam(INT-14),  Area(INT-8),  Feature.of.Size(306). 
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Entity  Name:  Total  Runout  Tolerance 

Entity  Number;  418 

A total  runout  tolerance  specifies  the  maximum  allowable  deviation  of  position  for  all  points 
on  the  toleranced  feature  during  one  complete  revolution  of  the  feature  about  the  datum  axis, 
with  relative  axial  displacement  of  the  measuring  position.  Where  applied  to  surfaces  constructed 
around  a datum  axis,  it  is  used  to  control  the  cumulative  variations  of  circularity,  straightness, 
angularity,  taper,  profile  of  surface,  and  coaxiality.  Where  applied  to  surfaces  constructed  at  right 
angles  to  the  datum  axis,  total  runout  controls  perpendicularity  and  flatness. 

See  ANSI  Y14.5M  1982,  page  109,  section  6.7.2  2 
See  ISO  1101,  page  22-23,  section  5.12 

Note  that  ANSI  and  ISO  do  not  explicitly  define  total  rimout  for  non-cylindrical  surfaces.  It  is 
assumed  that  this  is  due  to  mechanical  measurement  limitations. 

EXPRESS  Definition 

ENTITY  Total.Runout  SUBTYPE  OF  (Geometric.Tolerance) ; 

Tol.Ent  : SET  OF  SELECTf Area , Feature.of .Size ) ; 

Tolerance  : Number: 

Primary.datum  : Unconditioned.Datum ; 

Co-primary_datum  : Optional  Unconditioned.Datum; 

WHERE 

Tol.Ent  <>  []  ; 

Tolerance  > 0; 

{*  FOR  EACH  member  IN  Tol.Ent 

((CIRCULAR(member)  OR  DISK(member) ) ; *) 

END.ENTITY: 

Attribute  Definitions: 

Toleranced -Entity: 

A set  of  entities  to  which  the  tolerance  applies. 

Tolerance 

The  aUowable  deviation  of  the  measured  dimensional  value  from  the  design  nominal. 
Primary-datum 

A datum  entity  from  which  the  dimension  is  measured.  The  primary  datum  is  the  most 
important  datum  relative  to  the  tolerance. 

Co-primary-datum 

An  additionzd  datum  entity  which  establishes  an  axis  with  the  primary  datum. 
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Figure  D-30:  STRAIGHTNESS  IDEFIX  Diagram 
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Constraint  Definitions: 

FOR  EACH  member  IN  Tol.Ent  ( (CIRCULAR(member)  OR  DISK (member ) ) 

Asserts  that  each  member  in  the  ToLEnt  list  must  be  either  Cylindrical  or  a Disk  (See  Circu- 
lar-Runout for  definition). 

Propositions: 

Each  TotalJlunout(418)  tolerance 

• is  a Geometric. Tolerance(402). 

• has  datum  of  exactly  one  Unconditioned-Datum(310). 

• may  have  a co-datum  of  one  Unconditioned  Datum(310). 

• tolerance  1 or  more  Area(INT-8),  Feature  of  Size(306). 
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DIMENSIONS  OVERVIEW 

The  analysis  of  dimensions  brought  out  some  very  subtle  aspects  of  the  meaning  of  dimensions 
placed  on  engineering  drawings.  Ostensibly,  the  dimensions  define  the  theoretically  exact  shape 
of  the  modelled  object.  However,  further  analysis  reveals  meaning  imbedded  within  the  plane  of 
the  paper  in  which  the  dimension  is  drawn,  within  the  witness  lines  and  even  in  the  shape  of  the 
dimension  leaders.  The  aspect  of  the  dimension  with  the  least  meaning  is  the  dimensional  value.  All 
of  these  characteristics  are  added  together  with  a tolerance  value(s)  to  communicate  the  allowable 
shape  deviations  of  the  physical  object  produced  from  the  design  model  to  the  design  analysts, 
machinists  and  inspectors  who  use  them. 

For  example,  one  distinction  that  was  implicitly  made  in  earlier  versions  of  the  tolerance  model 
and  is  more  explicitly  dealt  with  in  these  extensions  is  the  difference  between  the  thing  which  is 
toleranced  versus  the  thing  controlled  by  the  tolerance  (for  the  Location  and  Angle  tolerances) 
The  plane  of  the  paper  of  a drawing  represents  a series  of  section  cuts  (parallel  to  the  plane  of  the 
paper)  through  the  object  representation  and  each  dimension  is  placed  within  one  of  these  section 
cuts.  Witness  Lines  or  leader  arrowheads  indicate  the  lines  or  planar  curves  within  a section  cut 
that  are  the  origin  and  target  for  the  dimension.  The  toleranced  thing  is  the  line  or  a point  on 
the  planar  curve  while  the  surface  being  controlled  by  the  dimension/ tolerance  combination  is  the 
surface  that  intersects  the  plane  of  the  section  cut  to  form  the  line  or  curve.  Another  example  is 
the  location  of  a hole  from  a plane:  the  thing  to  which  the  tolerance  applies  is  the  centerline  of  the 
hole,  but  he  thing  being  controlled  by  the  tolerance  is  the  surface  of  the  hole. 

NOTE:  Unlike  previous  entity  definitions,  the  Propositions  of  the  dimension  entities  contain 
information  that  is  not  captured  in  either  the  IDEF  or  the  Express  entity  definitions.  These 
propositions  are  part  of  the  entity  definition. 
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Entity  Name:  Coordinate  Dimension 

Entity  Number;  600 

A coordinate  dimension  corresponds  to  dimensions  typically  found  on  engineering  drawings. 
This  is  a classification  of  Location,  Size  and  Angle  dimensions. 

EXPRESS  Definition 

ENTITY  Coordinate.Dimension  SUPERTYPE  OF  (Size.Dimension , 

Angle.Dimension , Location.Dimension) ; 

END.ENTITY; 
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Entity  Name:  Size  Dimension 

Entity  Number;  601 

A Size  Tolerance  is  a numeric  range  that  constrains  the  value  of  a Size  Dimension.  A Size  Dimen- 
sion is  a measure  of  an  individual  feature  of  the  shape  of  an  object.  There  are  three  characteristics 
of  a Size  Dimension: 

1.  the  dimensional  value  (implicitly  defined  within  the  representation  geometry  or  explicitly 
cadled  out  in  a feature  definition); 

2.  the  shape  representation  elements  which  define  the  feature  of  interest;  and 

3.  the  center  of  symmetry  of  the  elements  of  the  feature. 

The  value  of  a Size  Dimension  is  expressed  as  a magnitude  and  is  independent  of  the  location  of  the 
feature.  The  feature  of  interest  must  be  a Feature  of  Size  (see  - ANSI  Y14.5)  which  are  characterized 
by  a point,  curve  or  surface  of  symmetry.  The  value  of  the  Size  Dimension  is  determined  by 
measuring  in  a straight  line  from  a point  on  the  feature  through  the  center  of  symmetry  (normal 
to  the  curve  or  surface  of  symmetry)  to  another  point  on  the  feature  opposite  the  first  In  most 
cases,  the  determination  of  th  dimensional  value  is  trivial,  as  in  the  diameter  of  a hole  or  the  width 
of  a slot. 

EXPRESS  Definition 

ENTITY  Size.Dimension  SUBTYPE  OF  (Coordinate.Dimension) ; 

Tolerance  : Coordinate_Tolerance_Range ; 

END.ENTITY; 

ENTITY  Size.Parameter  SUBTYPE  OF  (Size.Dimension) ; 

Paraineter.Value  : Optional  Number; 

WHERE 

MEMBER(Form_Feature ,1,1) ; 

END.ENTITY; 

ENTITY  Size.Characteristic  SUBTYPE  OF  (Size.Dimension) ; 

Dimensioned.Entity  : Feature.of .Size ; 

Center. of .Symmetry  : Geometry; 

END.ENTITY; 

Attribute  Definitions; 

Size-Dimension 

Size-Dimension  is  an  entity  that  specifies  a tolerance  range  for  a dimensional  aspect  of  a 
product  feature. 
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Figure  D-32;  COORDINATE  DIMENSION  IDEFIX  Diagram 
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Toleramce 

The  numeric  range  that  defines  the  allowable  deviation  of  the  size  dimension. 

Size-Parameter 

Implicit  Form  Features  typically  call  out  size  parameters  in  the  definition  of  the  Feature, 
such  as  the  diameter  of  a Hole.  A Size-Parameter  is  a type  of  Size-Dimension  that  spec- 
ifies that  value  of  the  parameter  and  a tolerance  on  the  parameter  (through  its  supertype 
Size-Dimension).  For  the  existence  of  this  entity  to  be  valid  it  must  be  referenced  by  some 
Implicit  Form  Feature. 

Parameter. Value 

The  numeric  value  of  the  size  parameter  for  a characteristic  of  a Implicit  Form  Feature.  In 
some  cases,  this  value  may  be  derivable  from  other  parameters  of  the  Implicit  Form  Features, 
therefore  this  value  is  left  optional;  thus  Size  Parameter  is  categorized  as  independent  or 
derivable.  This  implies  the  restriction  that  Derivable  Size  Parameters  (i.e.  specifies  no  explicit 
value)  must  be  DERIVEd  in  an  Implicit  Form  Feature. 

Size  Characteristic 

Explicit  shape  elements  may  have  dimensional  characteristic  to  which  a Size. Dimension  may 
be  applied.  Since  a Size-Dimension  only  applies  to  Features.of.Size,  the  shape  element  must 
be  defined  as  a Feature.of.Size  and  associated  with  its  Center.of-Symmetry.  The  Tolerance 
Range  then  applies  across  the  dimensioned  surfaces  through  the  Center.of-Symmetry. 

Dimensioned-Entity 

The  explicit  feature  of  the  product  shape  to  which  the  Size  Dimension  Tolerance  applies.  It 
must  be  a Feature.of.Size. 

Center.of-Symmetry 

Features.of.Size  are  characterized  by  a Center  of  Symmetry  and  the  the  dimension  and  tol- 
erance apply  across  the  center  of  symmetry. 

Propositions: 

• A Size  Tolerance  Range  (403)  applies  to  a Size  Dimension  (601) 

• A Size  Dimension  (601)  may  be  an  explicit  parameter  (604)  (attribute)  or  may  be  a calculated 
characteristic  (605)  of  a Feature  of  Size. 

• An  Implicit  Form  Feature  may  have  0,  1,  or  more  Size  Parameters. 

• A Size  Parameter  may  be  either  independent  or  derivable. 

• A Feature  of  Size  may  have  0,  1 or  more  Size  Characteristics. 

• A Size  Characteristic  of  a FOS  has  one  center  of  symmetry  (COS). 

• Some  Form  Features  are  Features  of  Size. 

• A Size  Feature  is  a Feature  of  Size. 
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Entity  Name;  Location  Dimension 

Entity  Number;  602 

A Location  Tolerance  is  a numeric  range  that  constrains  the  value  of  a Location  Dimension. 
A Location  Dimension  is  the  measurement  of  the  location  of  one  feature  with  respect  to  another 
feature.  It  is  either  directed  (i.e.  there  is  a distinction  between  the  origin  and  the  target  of  the 
dimension)  or  a bi-directional.  The  value  of  the  Location  Dimension  is  the  distance  between  two 
parallel  shape  representation  elements  or  things  derived  from  shape  representation  elements  (any 
combination  of  planar  su'eas,  linear  seam  or  comers,  or  two  elements  separated  by  a constant 
distance).  Each  feature  within  a Location  Dimension  consists  of  two  characteristics:  the  thing  to 
which  the  tolerance  applies  (or  is  the  origin  of  the  dimension)  and  the  actual  shape  representation 
element  (surface/eirea,  curve/seam  or  point/corner)  on  the  object  wliich  is  being  controlled  (or  is 
the  controlling  surface  of)  the  dimension  and  tolerance.  These  components  may  be  the  same  thing, 
i.e.  there  does  not  have  to  be  two  distinct  entities  (in  fact,  the  thing  being  controlled  may  be  implied 
through  the  thing  being  toleranced.) 

The  value  of  the  dimension  is  typically  measured  in  along  a linear  path,  although  arc  length 
and  “true”  dimensions  require  that  a path  be  specified  to  determine  the  actual  value  to  which  the 
tolerance  applies. 

This  is  not  to  imply  that  location  tolerances  may  apply  only  to  linear,  planar  and  offset  curves 
and  surfaces.  A complex  (shape  representation  elements  that  are  not  planar,  linear  or  cylindrical) 
Area  or  Seam  (the  thing  which  is  being  controlled  by  the  tolerance)  may  be  algorithmically  re- 
solved (through  a Geometric  Derivation)  to  a plane  or  line  (the  thing  which  is  toleranced),  thereby 
satisfying  the  stipulations  above. 


EXPRESS  Definition 


ENTITY  Location.Dimension  SUBTYPE  OF  (Coordinate.Dimension) 


Tolerance 

Target 

Origin 

Directed 

Linear 

Path 

WHERE 


Coordinate_Tolerance_Range ; 
DT.Feature ; 

DT.Feature ; 

Logical ; 

Logical 

Optional  Geometric.Derivation ; 


IF  Linear  THEN  Path  = NULL; 

IF  NOT  Linear  THEN  PATH  <>  NULL; 
END.ENTITY; 


Attribute  Definitions; 

Tolerance 

The  numeric  rsmge  that  defines  the  aUowable  deviation  of  the  location  dimension. 
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Figure  D-33:  SIZE  DIMENSION  IDEFIX  Diagram 
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Target 

In  a directed  dimension,  the  Target  is  the  feature  of  the  product  shape  that  represents  the 
“to”  entity  of  the  dimension. 

Origin 

In  a directed  dimension,  the  Origin  is  the  feature  of  the  product  shape  that  represents  the 
“from”  entity  of  the  dimension. 

Directed 

A true  or  false  value  that  indicates  whether  the  Location-Dimension  should  be  viewed  as  a 
“from” /“to”  dimension  or  whether  no  such  distinction  should  be  made.  “True”  means  that 
the  dimension  should  be  interpreted  “from”  the  origin  “to”  the  target.  “False”  means  that 
there  is  no  precedence  between  the  entities  involved  in  the  dimension. 

Linear 

In  most  cases,  a Location-Dimension  will  be  a linear  measurement  between  the  two  specified 
entities.  “Linear”  will  be  “true”  in  these  instances.  When  the  measurement  follows  some 
non-linear  path,  such  as  an  “arc  length”  or  “true”  dimension,  then  a measurement  path  must 
be  specified  and  “linear”  will  be  false. 

Path 

In  non-linear  dimensional  measurements,  a Path  for  the  measurement  must  be  specified. 

C_p n s t rai nt  Defi ni tio n sj 

If  the  dimension  is  linear,  then  no  path  is  specified.  If  non-linear,  then  a path  must  be  specified. 

The  target  and  origin  entities  called  out  by  a Location-Dimension  must  be  planar,  linear  or  a 
point,  OR  they  must  be  offset  from  one  another  by  a uniform  distance,  (see  propositions) 

Propositions; 

• A Location  Tolerance  applies  to  a Location  Dimension. 

• A Location  Dimension  may  be  a linear  measurement  of  the  distance  between  two  parallel 
shape  elements.  (“Parallel”  is  a single  valued  function;  points  are  parallel  to  everything.) 

• A Location  Dimension  may  be  a curvi-linear  measurement  between  shape  elements. 

• The  Path  of  a curvi-lineau  measurement  must  be  specified. 

• A Path  is  a Geometric  Derivation  which  specified  a curve. 

• The  target  and  origin  of  a Location  Dimension  must: 

1.  be  planar,  linear  or  a point; 

2.  be  a Geometric  Derivation  which  resolves  to  a plane,  line  or  point; 

3.  be  parallel  to  one  another  (offset,  curvi-linear  surfaces); 

4.  the  origin  may  be  reference  geometry. 
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Entity  Name;  Angle  Dimension 

Entity  Number;  603 

An  Angle  Tolerance  is  the  numeric  range  that  constrains  the  value  of  an  Angle  Dimension.  An 
Angle  Dimension  is  the  measure  of  the  orientation  of  one  feature  with  respect  to  another  feature 
An  Angle  Dimension  is  either  directed  in  the  same  sense  as  a Location  Dimension,  or  bi-directional 
in  the  same  sense  as  a Size  Dimension  (in  that  it  applies  to  a single  feature).  The  value  of  the 
dimension  is  the  angle  between  two  straight  shape  representation  elements  or  the  tiling  derived 
from  a shape  representation  element  (planar  areas,  Linear  seams  or  elements  which  have  a constant 
angular  relationship  to  one  another). 

Each  feature  within  a directed  Angle  Dimension  consists  of  two  characteristics,  as  in  the  Loca- 
tion Dimension: 

1.  the  thing  to  which  the  tolerance  applies  (or  is  used  as  the  origin  for  the  dimension);  and 

2.  the  actual  element  which  is  being  controlled  (or  is  the  controlling  element  for  the  dimension 
and  tolerance). 

These  characteristics  may  be  embodied  within  the  same  shape  element,  or  may  be  separate  elements 
in  the  case  of  complex  features. 

The  feature  within  a bi-directional  angle  (angle  size)  dimension  is  a Feature  of  Size  and  must 
be  composed  of  Linear  elements  equally  disposed  about  the  center  of  symmetry. 

A directed  Angle  Dimension  must  consist  of  two  additional  pieces  of  information  in  order  to 
determine  the  dimensional  value: 

1.  an  orientation  vector  (parallel  to  area  features  and  normal  to  seam  features)  to  establish  a 
right-hand-rule  for 

2.  a flag  that  indicates  the  CW  or  CCW  sense  of  measurement. 

A bi-directional  angle  (angle  size)  dimension  requires  one  additional  piece  of  information  to 
determine  the  toleranced  angle  value:  a flag  indicating  that  the  angle  of  interest  is  the  one  less 
than  180  degrees  or  greater  that  180  degrees. 


EXPRESS  Definition 

ENTITY  Angle.Dimension  SUBTYPE  OF  (Coordinate.Dimension) ; 
Tolerance  : Coordinate.Tolerance.Range ; 
END.ENTITY; 


ENTITY  Related_Angle_Dimension  SUBTYPE  OF 


Target 

Origin 

Sense 

Orientation 


DT.Feature ; 
DT.Feature ; 
Logical : 
Direction: 


(Angle.Dimension) ; 


WHERE 
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CQQMIMATE  DlMEHSIQN/600 


DIN  TYPE 
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LiHtAa 


f 

« 


CURYl 


-LINEAR  DIN/4022 


9 2 

DEFINES  THE  PATH  OF 
6EPNETRIC  DEHlYATIQH/m 


Figure  D-34:  LOCATION  DIMENSION  IDEFIX  Diagram 


199 


ISO  TC184  SC4  WGl 


ANNEX  D 
(Draft  Proposal 


October  31.  1988 


N2  8 8 


SECTION  3:  SHAPE  VARIATION  TOLERANCES 


((Target  <>  Corner)  AND  (Origin  <>  Corner)); 

END.ENTITY; 

ENTITY  Angle_Size_Parajneter  SUBTYPE  OF  ( Angle.Dimension)  ; 
Angle.Value  : Optional  Number; 

WHERE 

MEMBER (Form.Feature , 1 , #)  ; 

END.ENTITY; 

ENTITY  Angle.Size.Characteristic  SUBTYPE  OF  ( Angle.Dimension) ; 
Dimensioned.Entity  : Feature.of .Size ; 

Center. of .Symmetry  : Geometry; 

Characteristic. Angle  : Logical; 

END.ENTITY; 


Attribute  Definitions: 

Angle  Dimension 

Angle-Dimension  is  an  entity  that  specifies  a tolerance  range  for  an  angular  dimensional 
aspect  of  a product  feature. 

Tolerance 

The  numeric  range  that  defines  the  allowable  deviation  of  the  Angle.Dimension. 

Related -Angle -Dimension 

For  explicit  features  of  a product  shape,  a Related  Angle  Dimension  specified  the  “from”  and 
“to”  entities  of  an  Angle  .Dimension. 

Target 

As  in  a directed  Location.Dimension,  the  Target  is  the  feature  of  the  product  shape  which  is 
the  “to”  feature  in  a directed  angle  dimension. 

Origin 

As  in  a directed  Location-Dimension,  the  Origin  is  the  feature  of  the  product  shape  that 
represents  the  “from”  entity  of  the  dimension. 

Sense 

Sense  is  a Logical  value  that  indicates  whether  the  measurement  of  the  dimension  is  to  be  taken 
in  a clockwise  (TRUE)  or  counterclockwise  (FALSE)  direction  for  the  Related.Angle-Dimension. 
This  attribute  must  be  used  in  conjunction  with  the  orientation  vector,  otherwise  it  is  am- 
biguous. 

Orientation 

The  Orientation  Direction  (vector)  defines  the  Right-Hand- Rule  to  be  used  in  determining 
the  direction  of  measurement  for  the  Angle  Dimension.  This  is  to  be  used  in  conjunction  with 
the  Sense  flag. 
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Angle. Size-Parameter 

Implicit  Form  Features  may  angle  size  parameters  in  the  definition  of  the  Featu'-e,  such 
as  the  angle  of  a V-groove.  An  Angle.Size. Parameter  is  a type  of  Angle  Dimension  that 
specifies  that  value  of  the  parameter  and  a tolerance  on  the  parameter  (through  its  supertype 
Angle  Dimension).  For  the  existence  of  this  entity  to  be  valid  it  must  be  referenced  by  some 
Form  Feature. 

Angle-Value 

The  numeric  value  of  the  angle  parameter  for  a characteristic  of  a Form  Feature.  As  is  the 
case  of  the  size  parameter  value,  this  value  may  be  derivable  from  other  parameters  of  the 
Implicit  Form  Features,  therefore  this  value  is  left  optional;  thus  Angle  Size  Parameter  is 
categorized  as  independent  or  derivable.  This  implies  the  restriction  that  Derivable  Angle 
Size  Parameters  (i.e.  specifies  no  explicit  value)  must  be  DERlVEd  in  an  Implicit  Form 
Feature. 

Angle. Size -Char  act  eristic 

Explicit  shape  elements  may  have  dimensional  characteristic  to  which  a Angle.Size. Dimension 
may  be  applied.  Since  an  Angle.Size.Dimension  only  applies  to  Features.of.Size,  the  shape 
element  must  be  defined  as  a Feature.of.Size  and  associated  with  its  Center.of.Symmetry. 
The  Tolerance  Range  then  applies  across  the  Center.of.Symmetry. 

Dimensioned-Entity 

The  explicit  feature  of  the  product  shape  to  which  the  Angle  Size  Dimension  Tolerance  ap- 
plies. It  must  be  a Feature.of.Size. 

Center.of.Symmetry 

Features.of.Size  are  characterized  by  a Center  of  Symmetry  and  the  the  dimension  and  tol- 
erance apply  across  the  center  of  symmetry. 

Characteristic -Angle 

Characteristic-Angle  is  a flag  indicating  whether  it  is  the  angle  with  a measure  of  less  than 
180  degree  (TRUE)  which  is  the  intended  dimension  or  the  angle  greater  than  180  degrees 
(FALSE).  Is  the  angle  is  equal  to  180  degrees,  then  the  distinction  is  moot,  unneeded,  inde- 
terminate, don’t-worry-about-it-it’ll-  probably-never-happen. 

Propositions; 

• An  Angle  Toleramce  Range  (4013)  applies  to  an  Angle  Dimension  (603). 

• An  Angle  Dimension  (603)  may  be  a rotational  measurement  between  two  intersecting  shape 
elements. 

• An  Angle  Dimension  (603)  may  be  an  intrinsic  measure  of  a shape  element  and  therefore  has 
a center  of  symmetry. 

• The  value  of  the  Angle  Dimension  is  determined  from  the  origin  to  the  target  using  the 
right-hand-rule  plus  a direction  (view  vector)  for  explicit  measures. 
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• The  origin  and  the  traiTigVc  of  axi  An^ie  Dimension 

1.  be  a shape  elernrot  jriarfe  is  piaasar  or  linear; 

2.  be  a Geometric  Desi’vaarojn.  resolves  to  a pilane  cur  a Line; 
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3.6  Issue  Log 

The  purpose  of  this  issues  log  is  to  track  and  report  on  perceived  problems  withm  the  Tolerance 
Model.  Each  issues  consists  of  the  following  information: 

NUMBER; 

A sequentially  defined  number  identifying  the  issue.  The  number  consists  of  a prefix  indicating  the 
year  in  which  the  issue  was  raised  and  a suffix  which  is  simply  an  index. 

TITLE: 

A name  for  the  issue. 

INITIATION  DATE; 

The  date  the  issue  was  raised 

INITIATOR: 

The  person/project /meeting  that  raised  the  issue. 

STATUS; 

Indicates  the  current  activity  on  the  issue.  The  following  states  have  been  defined: 

Unresolved  No  work  is  being  done  to  resolve  the  issue. 

In  work  A resolution  to  the  issue  is  actively  being  sought  and  an  individual  or  group. 
Preliminary  A solution  has  been  proposed  and  is  currently  under  review.  Includes  proposal  date 
and  proposing  individual/committee. 

Resolved  A proposal  has  been  accepted  which  adequately  solves  or  satisfies  the  issue.  A Re- 
solved status  includes  the  date  of  resolution. 


RELATED  ISSUES; 

A list  of  numbers  of  the  issues  which  have  bearing  on  this  issue. 

DESCRIPTION; 

The  body  of  text  describing  the  issue.  This  includes  not  only  an  explanation,  but  also  identifies 
the  pertinent  entities/  attributes  /relationships  and  any  individuals  involved. 
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OPTIONS  &:  EVIDENCE: 

This  section  lists  identified  solutions  and  the  arguments  for  and  against  each  one. 

Option  # : Description  of  solution 
Pros  : Arguments  in  favor  of  solution 
Cons  : Arguments  against  solution 

OPTION  PROPOSED; 

An  option  selected  from  the  above  list  which  is  the  recommended  resolution  to  the  issue. 
EXPLANATION: 

Rationale  for  selecting  the  proposed  solution. 

DECISION: 

The  consensus  that  the  proposed  solution  should  be  approved  or  disaparoved.  Also  included  the 
identity  of  the  decision  making  body 

D J^IS ION  DATE: 

Date  of  decision. 

ACTION: 

The  decision  making  body  will  identify  the  individual  or  committee  responsible  for  implementing 
an  approved  solution. 
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ISSUE 

INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-86.1  ANGLE  TOLERANCE 
January  1986 

Mfg  Tech  Committee,  San  Diego  Meeting 
Resolved 

Superceded  by  87.2,  88.26 

The  method  used  to  provide  the  necessary  information  to  calculate  the 
intended  angular  measure  for  an  Angle  tolerance  were  points  which 
lie  on  the  intersection  of  the  two  entities  involved  in  the  tolerance 
at  which  tangent  vectors  to  the  entities  were  determined.  The  angle 
between  these  two  vectors  indicated  the  angle  to  which  the  tolerance 
applies.  There  is  some  question  as  to  whether  the  information  provided 
is  sufficient. 


ISSUE  OPTIONS  & EVIDENCE; 


Option  1: 


Pros 
Cons 
Option  2 


Pros: 

Cons; 


Define  a set  of  coordinate  triplets  (three  distinct  points)  that  are  associated  with  the 
Angle  Tolerance,  the  Toleranced  Entity  and  the  Tolerance  Origin.  One  point  of  each 
triplet  will  lie  on  the  intersection  of  the  Toleranced  Entity  and  the  Tolerance  Origin; 
one  point  will  lie  on  Ihe  Toleranced  Entity;  the  last  point  will  lie  on  the  Tolerance 
Origin.  Each  triplet  wiU  specify  the  point  at  which  the  tolerance  applies  and  allow 
the  calculation  of  the  value  intended  dimension  (the  intersection  point  is  the  vertex 
of  the  angle). 

This  satisfies  the  perceived  information  requirements  to  define  an  Angle  Tolerance. 
The  concept  and  model  of  the  proposed  solution  is  somewhat  complicated. 

Remove  all  coordinates  and  simply  have  the  Angle  Tolerance  reference  the  Toleranced 
Entity  and  the  Tolerance  Origin,  leaving  the  interpretation  up  to  the  individual 
systems. 

Simple  and  more  direct.  Most  Angle  Tolerances  will  be  simple  and  unambiguous, 
making  interpretation  of  the  Angle  Tolerance  a relatively  simple  matter. 

There  is  room  for  error,  misinterpretation,  and  inexactness  when  tolerancing  the  angle 
between  two  complex  surfaces  (such  as  a Ruled  Surface  and  Plane).  This  approach 
does  not  have  the  completeness  required  to  communicate  a complex  Angle  Tolerance. 


OPTION  PROPOSED: 

DECISION; 


DECISION  DATE: 
ACTION: 


NOTE: 


Option  #1.  The  model  implementing  this  solution  has  been  incorporated 
into  the  reference  model. 

The  Tolerance  Application  Committee  decided  that  the  proposed  solu- 
tion more  completely  represents  the  intention  of  Angle  Tolerances.  The 
coordinate  triplets  are  optional  associations  that  may  be  included  in  the 
definition  of  an  Angle  Tolerance  for  more  specificity,  but  do  not  have  to 
be  included  for  simple  cases. 

19‘^  December  1986 

Tolerance  Application  Committee  has  incorporated  the  approved  solution 
into  the  Tolerance  Reference  Model 

Resolution  superceded  by  subsequent  model  development. 
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ISSUE 

INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-86.2  SIZE  TOLERANCED  ANGLE 
August  1986 

Mechanical  Products  Committee,  Peoria  Project. 

Resolved 

N/A 

The  definition  for  a Size  Tolerance  states  that  the  tolerance  value  ap- 
plies to  a dimension  of  the  toleranced  feature  which  is  independent  of 
the  feature’s  location.  This  definition  allows  the  size  of  an  angle  to  be 
toleranced  as  well.  This  added  interpretation  seems  to  logically  make 
sense,  but  the  model  does  not  explicitly  allow  for  it. 


ISSUE  OPTIONS  &:  EVIDENCE: 

Option  1;  Expand  the  definition  of  the  Size  Tolerance  to  include  the  tolerancing  of  the  size 
of  the  angle  between  two  entities  which  are  symmetrically  disposed  about  a center 
plane,  line,  axis  or  point.  This  may  require  the  addition  of  a flag  to  the  Size  Tolerance 
Entity  to  denote  that  the  tolerance  applies  to  the  angle. 

Option  2:  Create  an  “Angle  Dimension”  which  is  subtyped  as  a Related  Angle  Dimension  and 
an  Angle  Size  Dimension.  See  the  definition  of  Angle  Dimension  (604) 


OPTION  PROPOSED;  Option  2 

DECISION;  Option  2 has  been  incorporated  as  a category  of  Angle  Dimension. 
DECISION  DATE:  13'^'  July  1988,  Denver 
ACTION;  Tolerance  Committee 
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ISSUE: 

INITIATION  DATE: 
INITIATOR: 
STATUS: 
RELATED  ISSUES: 
DESCRIPTION: 


TOL-86.3  APPLICATION  OF  TOLERANCES  TO  TOPOL- 
OGY VS  GEOMETRY 

Many  different  times  (for  the  record,  Dec  86) 

Again,  many  (for  the  record.  Tolerance  Appl.  Com. 

Resolved 

N/A 

Are  tolerances  more  appropriately  applied  to  topology  or  geometry 
entities?  Topology  all  by  itself  defines  logical  connectivity,  whereas 
geometry  defines  the  mathematical  shape  of  an  object.  It  would  seem 
that  since  tolerances  control  the  shape  of  the  produced  object  and  it 
is  the  mathematical  definition  of  that  shape  which  is  subject  to  %’aria- 
tion,  the  tolerances  would  more  appropriately  be  apalied  to  geometry 
entities.  Geometry  alone,  however,  does  not  adequately  describe  the 
shape  of  a part  because  the  boundaries  of  the  geometric  elements  (if, 
indeed,  bounded)  do  not  neessarily  correspond  to  real  boundaries  of 
the  faces  on  a physical  object,  or  may  correspond  to  several. 


ISSUE  OPTIONS  & EVIDENCE: 


Option  1:  Apply  Tolerances  to  geometry  entities  rather  than  topology  entities. 

Pros:  This  option  is  intuitively  pleasing  beause  the  tolerance  is  compared  to  the  measured 
deviation  of  the  mathematical  (geometric)  definition  of  a surface  (or  other  feature) 
on  a produed  (physical)  object  from  the  theoretical,  mathematical  (geomDtric)  def- 
inition of  the  corresponding  surface  (or  other  feature)  in  the  (solids)  model  of  the 
object.  It  is  the  geomDtric  definitions  of  phe  surfaces  which  are  compared. 

Cons:  The  problem  with  this  option  is  that  geometry  funions  in  many  different  roles,  only 
one  of  which  is  defining  the  shape  of  an  object.  Even  the  geometry  which  defines 
the  shape  sometimes  is  not  speific  enough  to  be  used  in  conjuction  with  a tolerance. 
Several  different  faces  may  share  the  same  surface  definition  and  it  would  be  incorrect 
to  imply  that  both  faces  must  always  share  the  same  tolerance  as  well.  Also,  a 
face  may  define  a portion  of  an  unbounded  surface,  and  a tolerance  applied  to  an 
unbounded  surface  makes  no  sense  beause  unbounded  surfaces  cannot  be  measured. 


Option  2:  Leave  approach  as-is  a enhance  the  explanation  of  the  intention  of  the  Faces,  Edges 
and  Vertices  described  in  the  model. 

Pros;  The  concept  of  Face,  Edge  and  Vertex  adequately  serve  the  needs  of  the  Toler- 
ance Model.  To  impose  the  constraints  implied  by  hese  constructs  on  geometric 
elements  would  be  difficult,  awkward  and  confusing.  The  explanation  within  the 
Model  Assumptions  states  that  Topologic  elements  always  have  underlying  gccmct 
ric  definitions.  Also  stated  within  the  Model  Assumpnions  is  that  the  constructs 
Face,  Edge  and  Vertex  as  defined  with  a BREP  Solid  Model  are  not  required,  but 
that  their  funtional  equivalent  is  required.  This  allows  the  Tolerance  Model  to  ref- 
erence Faces /surfaces  which  correspond  to  actual,  physical,  touchable  portions  of  a 
produced  object. 
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Cons: 

Option  3: 
Pros: 


Cons: 


Implies  a requirement  for  BREP  Solid  Model,  Is  intuitively  unappealiiig  because 
topology  doesn’t  always  have  shape  (e.g  schematics.) 

Rename  entities  in  accordance  with  work  of  Integration  Commjttee. 

The  concept  of  “Shape  Elements”  as  defined  by  the  Integration  commitnee  core- 
sponds exactly  with  the  use  of  “Face,  Edge  and  Vertex”  within  phe  Tolerance  Model. 
By  removing  the  BREP-ish  nature  of  the  models  “integration  entities”,  this  issue 
becomes  moot. 

None 


OPTION  PROPOSED:  Option  3.  The  Tolerance  Models  use  of  topological  terms  mislead  and 

confused  the  intent.  The  concept  of  Shape  Elements  embody  the  correct 
viewpoint  of  the  model  and  make  this  issue  moot. 

DECISION:  The  Tolerance  Application  Committee  has  approved  the  solution. 
DECISION  DATE:  29"^  March  1988 
ACTION:  Tolerance  Committee 


N288 
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ISSUE:  TOL-86.4  TOLERANCES  TO/FROM  DERIVED  GEOMETRY 


INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


19‘^  December  1986 

Tolerance  Application  Committee,  St.  Louis 
Resolved 

Superceded  by  88.1 

The  point  was  made  that  some  tolerances  apply  to  geometry  entities 
which  do  not  have  a corresponding  topology  entity;  gauge  points  and 
breakout  tangency  planes  were  cited. 


ISSUE  OPTIONS  k EVIDENCE: 

Option  1:  Add  an  entity  called  Derived  geometry  as  a candidate  Toleranced  Entities  and  Toler- 
ance Origins  for  coordinane  tolerances.  The  stipulation  is  that  the  Derived  geometry 
must  be  calculable  from  produt  topology  (e  g.  spatial  intersetion  curves,  centerlines). 
Each  type  of  Derived  geometry  must  be  defined. 

Pros:  iSatisfies  perceived  need  for  Tolerance  to/from  off-part  geometry. 

Cons:  Open  ended  and  ill-defined.  Similar  to  the  dilemma  of  form  feature  enumeration. 


OPTION  PROPOSED: 

DECISION: 


DECISION  DATE; 
ACTION: 

NOTE: 


Option  1. 

The  Tolerance  Application  Committee  agreed  that  the  need  for  such  a 
construct  exists.  However,  the  time  to  fully  explore  this  topic  is  not 
currently  available.  Therefore,  an  entity  called  Derived  Geometry  will  be 
added  and  treated  like  Faces,  Edges,  Vertices,  Size  Features  and  Features 
of  Size.  An  explanation  of  the  intent  and  purpose  of  tiiis  entity  will  be 
included,  with  the  assertion  that  it  will  be  analyzed  in  the  future,  but  no 
further  definition  of  it  will  be  made.  See  example  for  the  purpose  and  use 
of  this  entity. 

19‘^  December  1986 

Tolerance  Application  Committee 

The  proposal  made  in  the  resolution  to  this  issue  has  been  expanded  upon 
in  the  work  of  the  committee  dated  Mairch  1988.  See  88.1  for  more 
detzdls. 
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ISSUE 

INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-86.5  TOLERANCE  ENTITY  DISPLAY 
19‘^  December  1986 

Tolerance  Application  Committee,  St,  Louis 

Preliminary 

N/A 

A practical  requirement  of  all  entities  is  the  ability  to  see  and  manip- 
ulate the  entities.  How  are  Tolerances  Entities  to  be  displayed'’  This 
raises  two  questions:! 

1)  will  an  answer  to  this  question  be  of  value?;  and 

2)  is  this  the  responsibility  of  the  Tolerance  Application  Committee? 
The  answer  to  1)  is  obviously  yes;  in  fact  it  is  almost  a requirement. 
The  answer  to  2)  is  no,  it  is  not  the  responsibility  of  the  TAC. 


ISSUE  OPTIONS  k EVIDENCE: 


Option  1: 

Pros: 

Cons: 
Option  2: 


Pros: 

Cons: 


Recommend  to  some  authoritative  body  that  they  take  action  on  this  subject  and 
await  a solution. 

1 This  problem  will  be  faced  by  many  application  committees  and  should  be  addressed 
level  common  to  all  of  them. 

It  may  never  get  done  with  this  approach. 

Add  three  pieces  of  information  to  the  generic  Tolerance  Entity  (which  thereby  applies 
to  all  tolerance  entities): 

1)  a coordinane  (point)  location  on  the  toleranced  entity,  2)  a coordinate  (point) 
location  of  the  tolerance  symbol,  and 

3)  an  orientation  (vector  or  plane)  in  which  the  symbol  is  visible. 

1 This  provides  sufficient  information  for  the  display  of  Tolerance  Entities. 

This  solution  may  not  be  appropriate  for  all  application  committees. 


OPTION  PROPOSED: 

DECISION: 


DECISION  DATE: 
ACTION: 


Option  2. 

After  a long  waiting  period  during  which  no  more  appropriate  committee 
addressed  this  problem,  the  Tolerance  Committee  decided  to  define  the 
information  needed  to  display  a tolerance  entity.  A proposal  will  be 
prepared  outUning  the  approach  along  the  line  suggested  in  Option  2. 
29‘'‘  March  1988 
The  Tolerance  Committee. 
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TOL-86.6  TOLERANCES  TO/FROM  PART-IN-FROCESS 

SHAPE 

19^^  December  1986 

Tolerance  Application  Committee,  St.  Louis 

Resolved 

N/A 

Can  Tolerances  span  intermediate  part  shapes'!*  Surfaces  are  often 
machined  based  on  dimensions  from  machined  tooling  surfaces  which 
will  not  be  present  in  the  final  part. 


ISSUE  OPTIONS  & EVIDENCE: 


Option  1: 
Pros: 

Cons: 


Take  no  action 

Doesn’t  really  seem  to  be  a tolerance,  but  more  of  a BASIC  dimension.  In  any  case, 
it  is  outside  the  scope  of  this  model. 

N/A 


OPTION  PROPOSED:  Option  1.  At  his  time  there  appears  to  be  no  need  to  pursue  this  issue 

further. 

DECISION:  Adopt  Option  1. 

DECISION  DATE:  19‘^  December  1986 
ACTION:  None. 
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TOL-86.7  BASIC  DIMENSIONS 
Various  (f  t .r.  19'^  December  1986) 

Various  (f.t.r.  19‘^  December  1986) 

Resolved 

87.2 

Should  BASIC  dimensions  as  described  in  the  standards  be  addressed 
within  this  model? 


ISSUE  OPTIONS  & EVIDENCE: 


Option  1: 
Pros: 
Cons: 

Option  2: 
Pros: 


Cons: 

Option  3: 
Pros: 
Cons: 


Take  no  action. 

BASIC  dimensions  are  currently  cursorily  addressed  within  the  model. 

BASIC  dimensions  are  part  of  the  standard  and  should  be  accommodated  within  phe 
refeence  model. 

Remove  any  reference  To  BASIC  dimensions  from  model. 

Because  of  the  assumption  that  the  geometry  in  the  product  model  defines  the  theo- 
retically exact  shape,  the  model  is  in  effect  BASIC  and,  therefore,  BASIC  dimensions 
do  not  need  to  be  explicitly  addressed. 

BASIC  dimensions  are  part  of  the  standard  and  should  be  accommodated  within  phe 
refeence  model. 

Enhance  the  capability  of  the  reference  model  to  handle  BASIC  dimensions. 

Will  satisfactorily  address  the  issue  by  coming  up  with  a thought  out  answer. 

Will  take  more  time  than  is  available,  and  the  issue  is  not  cruial  to  the  usefulness  of 
the  reference  model. 


OPTION  PROPOSED: 


DECISION: 

DECISION  DATE: 
ACTION: 


Option  2.  The  Tolerance  Application  Committee  felt  that  the  argument 
in  favor  of  Option  2 was  the  strongest.  Option  1 would  be  adequate,  but 
it  would  open  the  door  to  confusion.  Option  3 was  deemed  unsatisfactory 
in  interest  of  time  and  importance. 

All  references  to  BASIC  dimensions  in  the  reference  model  will  be  re- 
moved. A statement  explaining  the  role  of  BASIC  dimensions  within  the 
approach  embodied  by  this  model  wdll  be  added  to  the  assumptions. 

19*^  December  1986 

Tolerance  Application  Committee 
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RELATED  ISSUES; 
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TOL-86.8  DEFAULT  TOLERANCES 
Various  (f.t.r.  December  1986) 

Various  (f.t.r.  19‘^  December  1986) 

Resolved 

N/A 

Default  tolerances  of  some  kind  are  present  on  virtually  all  drawings. 
How  is  the  need  for  this  capability  addressed  within  the  modeU  It  was 
agreed  within  the  Tolerance  Application  Committee  that  he  appropri- 
ate default  toleramce  for  a three  dimensional  geometric  model  would  be 
a Profile  of  a Surface  tolerance  applied  to  all  otherwise  unntoleraiiced 
surfaces  of  the  model. 


ISSUE  OPTIONS  k EVIDENCE: 


Option  1: 


Pros: 

Cons: 


Option  2: 


Pros: 

Cons: 


Option  3 
Pros 
Cons 


Include  statement  in  Assumptions  that  Profile  of  a Surface  tolerance  would  apply  to 
all  otherwise  untoleranced  surfaces  of  the  model.  The  value  of  the  tolerance  would 
be  located  somewhere  else  within  the  product  model. 

This  is  the  current  approach  taken  in  the  reference  model  and  would  require  no 
modifications  to  it. 

The  value  of  phe  default  tolerance  is  not  readily  available.  It  should  not  be  included 
in  another  reference  model,  but  should  be  located  within  the  Tolerance  model.  Tlus 
option  does  not  address  the  possibility  of  other  kinds  of  default  tolerances. 

Modify  the  Profile  of  a Surface  entity  to  include  a flag  indicating  whether  it  is  default 
or  not.  A stipulation  would  be  included  in  the  definition  of  the  entity  wliich  states 
that  only  one  Profile  of  a Surface  entity  with  the  default  flag  set  TRUE  may  be 
present  within  a given  product  model. 

The  default  tolerance  is  explicitly  addressed  by  the  reference  model  and  it  is  clear 
what  he  default  toleramce  is. 

The  possibility  tht  two  or  more  entities  may  exist  which  are  identified  as  default  is 
not  prohibited  other  than  by  the  stipulation  in  the  definition.  Does  not  address  the 
possibility  of  other  kinds  of  default  tolerances. 

Further  investigation  into  default  tolerances. 

Will  provide  a more  complete  solution. 

Time  constraints  prohibit  a thorough  investigation. 


OPTION  PROPOSED:  Option  2.  The  Tolerance  Application  committee  felt  that  the  argument 

for  Option  2 amd  against  Option  1 were  strong  enough  to  select  Option 
2.  Option  3 was  not  considered  at  this  time  due  to  time  constraints.  It  is 
recognized  that  the  argument  against  Option  1 and  2 about  other  kinds 
of  default  tolerances  is  valid.  At  some  point  in  the  future,  when  Option 
3 becomes  feasible,  it  is  likely  that  the  approach  described  by  Option  2 
wiU  be  carried  over  to  other  kinds  of  tolerances. 

DECISION:  The  reference  model  will  be  changed  to  reflect  the  approach  described  in 
Option  2. 
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TOL-86  9 RELATIONSHIP  BETWEEN  FORM  FEATURE. 

FEATURE-OF.SIZE,  AND  SIZE-FEATURE 

19‘^  December  1986 

Tolerance  Application  Committee 

Preliminary 

N/A 

A Form  Feature  is  a collection  of  geometric/topologic  elements  with  a 
name  that  cormotes  a special  shape  or  meaning  (e  g.  hole,  slot,  groove). 
Feature.of.Size  is  the  name  of  a classification  of  things  which  exhibit 
symmetry  about  a surface,  curve  or  point  and  is  defined  for  the  Tol- 
erance Application  referenced  model  (i.e.  it  wiU  not  be  used  in  other 
reference  models.)  A Size  Feature  is  the  name  of  an  entity  defined 
within  the  Tolerance  Application  reference  model  to  serve  as  a sur- 
rogate in  the  absence  of  defined  Form  Features.  A Size  Feature  is  a 
Feature.of.Size  and  the  idea  of  Feature  .of.Size  is  required  for  the  Tol- 
erance Application.  The  Tolerance  Application  Committee  agrees  on 
the  fundamental  relationship  between  these  concepts.  The  relationship 
is  described  by  the  following  Venn  diagram  (exaimples  in  each  set  are 
included):  - , 


A Size  Feature  is  a Feature.of  Size  but  is  not  a torm  reacure.  ouiuc 
Form  Features  are  Features.of-Size.  A hole  is  both  a Form  Feature  and 
Feature.of.Size.  IDEF-IX  cannot  model  this  situation,  so  the  issue  is 
“what  is  the  best  way  to  model  this  relationship’” 


ISSUE  OPTIONS  & EVIDENCE: 


Option  1: 
Option  2: 
Option  3: 

Option  4: 


Redefine  terms. 

Violate  IDEF-lX  and  allow  a categorization  to  have  two  generic  parents. 

Create  an  association  (intersetion  entity)  between  categories  of  Form  Feature  and 
Feature.of.Size  to  achieve  this  dual-parent  relationship. 

Since  Feature.of.Size  is  only  used  in  the  Tolerance  Application  reference  model,  create 
an  optional  relationship  between  a Form  Feature  and  a category  of  Feature  of  Size 
such  that  whenever  a Form  Feature  is  used  as  a Feature.of.Size,  it  is  identified  as 
such. 

The  Pros  and  Cons  of  the  above  options  consists  primarily  of  pictures  and  are  avail- 
able from  the  chaiirman. 


OPTION  PROPOSED:  The  current,  working  solution  is  Option  4.  Options  1 and  2 were  deemed 

inadequate  by  the  Tolerance  Application  Committee.  Option  3 was  awk- 
ward. Option  4 satisfied  the  current  needs  of  the  Tolerance  Application 
reference  model. 
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DECISION: 


DECISION  DATE: 
ACTION: 


SECTION  3:  SHAPE  VARIATION  TOLERANCES 


The  changes  described  in  Option  4 have  been  incorporatedd  into  thc 
reference  model.  However,  the  Tolerance  Application  Comrruttee  does 
not  recommend  this  as  a firm  solution  because  it  does  describe  the  same 
situation  as  in  the  Venn  diagram.  A final  decision  will  await  comments 
and  review. 

N/A 

Tolerance  Appbcation  Committee 
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TOL-86.10  APPLICATION  OF  MATERIAL  CONDITION 

MODIFIER 

December  1986 

Tolerance  Application  Committee 

Resolved 

N/A 

The  Material  Condition  Modifier  (MCM  - M/MMC:  Maximum  Mate- 
rial Condition;  L/LMC:  Least  Material  Condition;  S/  RES;  Regardless 
of  Feature  Size)  only  is  applicable  when  the  feature  of  interest  (i  e.  the 
toleranced  entity,  tolerance  origin,  or  datum)  is  a Feature  of  Size.  An 
analysis  of  ANSI  Y14.5M  1982  turned  up  no  counter  examples.  In  fact, 
section  2.8  specifically  states  that  the  MCM  applies  to  feature  subjet 
to  variation  in  size. 


ISSUE  OPTIONS  k EVIDENCE: 


Option  1: 


Pros: 

Cons: 


Categorize  Datum  into  Conditioned  and  Unconditioned;  the  conditioned  Daiium  con- 
tain the  MCM  indicator  and  is  defined  by  a Featuie.oLSize.  The  MCM  indicator 
with  the  Tolerance  Entities  is  changed  po  include  an  ”N”  for  not  applicable  and  a 
stipulation  is  added  to  Lhe  definition  explaining  when  it  is  and  is  not  applicable. 
Satisfies  the  problem  presented  by  he  issue. 

None  to  speak  of. 


OPTION  PROPOSED:  Choice  of  1.  Other  options  were  not  examined  beause  the  Tolerance 

Application  Commitnee  felt  that  this  solution  satisfactorily  addressed 
the  issue. 

DECISION:  Change  the  reference  model  to  reflect  the  changes  described  in  Option  1. 


DECISION  DATE. 
ACTION: 


19‘^  December  1986 

Tolerance  Application  Committee 
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TOL-86.11  LOCATION  TOLERANCE  COORDINATES 
December  1986 

Tolerance  Application  Committee 

Resolved 

86.1,  87.2,  88.26 

There  is  an  ambiguity  in  the  meaning  and  intent  of  the  coordinate 
associated  with  the  Toleranced  Entity  and  the  Tolerance  Origin  of 
the  Location  Tolerance.  Does  a dimension  exist  in  3-space  or  is  it  a 
strictly  planar  idea?  What  is  the  relationship  between  the  coordinates 
on  either  entity?  Do  Ihey  exist  to  be  more  specific  on  the  intention 
of  the  tolerance  or  merely  to  facilitate  the  calculation  of  the  desired 
dimension? 

With  the  idea  of  “path,”  the  answer  to  the  last  question  is  both.  The 
two  coordinates  and  path  are  included  in  the  definition  of  location  tol- 
erance to  provide  information  which  is  implicit  in  a location  toleranced 
dimension  on  a drawing  but  not  readily  identifiable.  The  plane  of  the 
paper,  leaders,  witness  lines  and  the  view  of  the  product  all  provide 
information  beyond  “this  is  so  far  from  that  plus-or-minus  this.” 


ISSUE  OPTIONS  & EVIDENCE: 


Option  1: 


Pros: 


Cons: 
Option  2: 


Pros: 

Cons: 


To  reduce  possible  ambiguity  in  meaning  and  make  simple  cases  more  straightforward, 
the  Location  Tolerance  should  be  allowed  to  tolerance  only  a single  entity  and  the 
coordinates  should  be  made  optional. 

Restricting  the  Location  Tolerance  to  a single  toleranced  entity  reduces  the  possibility 
of  misinterpretation  of  the  meaning  of  the  coordinates.  Optional  vs.  required  coor- 
dinates makes  simple  cases  (e.g.  distance  between  two  parallel  planes)  more  straight- 
forward. 

Doesn’t  fully  address  the  problem. 

Expand  on  the  idea  of  a “location  dimension”  which  explicitly  contains  information 
that  allows  a simple  determination  of  phe  value  to  which  the  tolerance  applies.  De- 
tails of  this  option  are  contained  in  the  description  of  the  location  dimension  in  the 
Tolerance  Model  Version  3.0. 


OPTION  PROPOSED: 

DECISION: 

DECISION  DATE: 
ACTION: 


Option  2. 

The  adoption  of  Option  2 actually  makes  the  issue  moot.  Formal  accep- 
tance of  the  resolution  closes  this  issue. 

13‘^  July  1988 

Tolerance  Application  Committee 
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TOL-86.12  CONSTRAINTS  BETWEEN  TOLERANCES 
December  1986 

Tolerance  Application  Committee 

Unresolved 

N/A 

Should  constraints  between  tolerances  be  modelled'!’  Some  tolerances 
imply  or  take  into  account  other  tolerances  (a  cylindricity  tolerance 
also  controls  the  circularity  of  the  toleranced  entity.) 


ISSUE  OPTIONS  & EVIDENCE: 

Not  applicable. 


OPTION  PROPOSED:  Not  Applicable. 

DECISION:  The  Tolerance  Application  Committee  has  left  tliis  issue  open.  Such 
situations  do  exist  and  are  identified  in  the  stannard,  but  the  worth  of 
including  them  in  the  reference  model  was  questionable.  Addressing  them 
would  elinunate  the  possibility  of  over-toleranced  or  conflicting  toleranced 
features,  but  it  was  felt  that  this  was  a question  of  good  D T practice 
and  outside  the  scope  of  the  reference  model.  A formal  deision  will  be 
made  when  comments  and  reviews  have  been  made. 

DECISION  DATE:  Not  AppUcable 
ACTION:  Not  Applicable 
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TOL-86.13  DATUM  TARGETS  AND  TAPER  TOLERANCES 
December  1986,  January  1988 
Tolerance  Application  Committee,  Bob  Parks 
Unresolved 
N/A 

Datum  target  and  Taper  Tolerances  as  specified  in  the  ANSI  standard 
(sections  2.13,  2.14,  pgs.  25-27)  are  not  addressed  by  the  reference 
model. 


ISSUE  OPTIONS  & EVIDENCE: 

Not  applicable. 


OPTION  PROPOSED:  xNot  Applicable 

DECISION:  The  Tolerance  Application  Committee  recognizes  this  as  a deficiency.  A 
solution  will  be  developed  in  the  future. 

DECISION  DATE:  Not  Applicable 
ACTION:  Not  Applicable 
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December  1986 

Tolerance  Application  Comrmttee 

Preliminary 

N/A 

IDEF-EX  lias  been  chosen  as  the  language  for  the  reference  models 
developed  for  PDES.  Does  the  Logical  Layer  Committee  require  syn- 
tactically correct  IDEF-lX  model  or  can  conventions  be  adopted  within 
delivered  models?  The  current  reference  model  is  not  in  a fully  devel- 
oped IDEF-lX  format  and  contains  syntactic  erors.  Specifically,  the 
model  does  not  identify  Key  attributes  of  entities  (rather  uses  “surro- 
gate” keys:  XXXX-id),  does  not  distinguish  between  identifying  and 
non-identifying  relationships,  and  does  not  distinguish  between  inde- 
pendent and  dependent  entities  (among  others.) 


ISSUE  OPTIONS  & EVIDENCE: 


Option  1: 
Pros: 
Cons: 
Option  2: 

Pros: 


Cons; 


Revise  model  in  accordance  with  IDEF-lX  rules 

7 

Will  pake  a considerable  amount  of  time  to  convert  the  model. 

Leave  refeence  model  as-is  and  explain  the  author  conventions  adopted  within  the 
reference  model  in  the  assumptions  setion. 

iThe  deviations  from  IDEF-lX  are  consistent  and  not  major  with  respect  to  the 
activities  of  the  Logical  Layer  Committee.  The  reference  model  may  still  be  read  as 
an  IDEF-lX  model. 

Uses  of  the  reference  model  which  require  a complete,  syntactically  correct  reference 
model  will  be  unable  To  use  the  Tolerance  Application  refeence  model. 


OPTION  PROPOSED: 


DECISION: 


DECISION  DATE: 
ACTION: 


Option  2.  Due  to  time  considerations,  the  reference  model  should  deliv- 
ered in  as-is  condition.  There  has  been  no  identified  reason  for  delivering 
a model  which  completely  adheres  to  IDEF-lX. 

The  Tolerance  Application  Committee  has  decided  to  adopt  the  solution 
proposed  in  Option  2.  Conversion  of  the  model  to  pure  IDEF-lX  will  be 
considered  for  future  versions  of  the  model. 

19‘^  December  1986 

Tolerance  Application  Committee 
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TOL-86.15  SOLICITING  REVIEW  OF  MODEL 

19'^  December  1986 

Tolerance  Application  Committee 

Unresolved 

N/A 

The  size  of  the  Tolerance  Application  reference  model  is  intimidating 
(although  the  content  is  not  overwhelming)  and  will  inliibit  quality 
review.  What  is  the  best  way  to  solicit  a good  review  of  the  model? 


ISSUE  OPTIONS  k EVIDENCE: 


Not  applicable. 

OPTION  PROPOSED:  Not  Applicable 
DECISION:  Not  Applicable 
DECISION  DATE:  Not  Applicable 
ACTION:  Not  Appbcable 
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DESCRIPTION: 


TOL-86.16  TYPES  OF  DATUM  ENTITIES 
December  1986 

Tolerance  Application  Committee 

Unresolved 

88.17 

The  types  or  nature  of  entities  (e.g.  “planar”  face)  which  may  be  tol- 
eranced  by  a given  tolerance  entity  are  constrained.  Should  the  type 
of  entities  which  serve  as  datums  for  given  tolerances  be  similarly  con- 
strained'^ 


ISSUE  OPTIONS  & EVIDENCE: 


Not  applicable. 

OPTION  PROPOSED:  Not  Applicable 
DECISION:  Not  Applicable 
DECISION  DATE:  Not  Applicable 
ACTION:  Not  Applicable 
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(Draft  Proposal 

SECTION  3:  SHAPE  VARIATION  TOLERANCES 


ISSUE: 

INITIATION  DATE: 
INITIATOR 
STATUS: 
RELATED  ISSUES: 
DESCRIPTION; 


TOL-87.1  UTILITY  OF  TOLERANCING  EDGES  AND  \ ER- 
TICES 

21*'  August  1987 
Bob  Johnson 
Unresolved 
N/A 

Since  “faces”  of  a part  are  the  features  which  are  actually  produed  and 
inspected,  is  there  utility  in  applying  tolerances  to  edges  and  vertices’’ 
What  do  tolerances  appUed  to  edges  of  vertices  really  mean;  doesn’t 
such  a tolerance  imply  a tolerance  to  or  control  of  the  adjacent  faces’’ 
Isn’t  he  ideal  situation  for  CIM  to  work  only  to  the  surfaces  of  the 
part? 


ISSUE  OPTIONS  k EVIDENCE: 

Not  applicable. 

OPTION  PROPOSED:  Not  Applicable 
DECISION:  Not  Applicable 
DECISION  DATE:  Not  Applicable 
ACTION;  Not  Applicable 


N288 


226 


ISO  TC184  SC4  WGl 


ANNEX  D 
(Draft  Proposal 

SECTION  3:  SHAPE  VARIATION  TOLERANCES 


N28S 

October  31.  1988 


ISSUE 

INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-87,2  DIMENSIONS 

21"  August  1987 

Bob  Johnson 

Resolved 

86.1,  88.26,  88.5 

The  tolerances  defined  in  this  reference  model  imply  underlying  dimen- 
sions of  the  geometric  model,  particularly  he  Coordinate  Tolerances. 
While  dimensionality  is  inherent  in  the  model  geometry  and  dimen- 
sions can  be  derived,  the  fact  that  a dimension  has  been  called  out  by 
a designer  implies  more  meaning  than  simply  the  dimensional  value. 
It  implies  a critical  relationship  between  features  on  the  part  which 
must  then  be  checked  by  QA.  The  implicitness  of  the  dimension  in  the 
tolerances  burys  the  significance  of  specifying  a dimension.  Therefore, 
the  aspect  of  “dimensions”  as  incorporated  in  the  Tolerance  reference 
model  should  be  explained  in  greater  detail. 


ISSUE  OPTIONS  & EVIDENCE: 


Option  1;  Expand  on  Ihe  idea  of  Location,  Angle  and  Size  dimensions.  Version  3.0  of  the 
Tolerance  Model  contains  a proposed  expansion  on  the  idea  of  dimension. 


OPTION  PROPOSED: 

DECISION: 


DECISION  DATE: 
ACTION: 


Option  1. 

The  proposal  appears  to  satisfy  the  concerns  expressed  in  this  issue,  al- 
though it  is  recognized  that  deeper  implications  of  this  issue  may  be 
missed.  Any  omissions  will  be  documented  as  new  issues. 

July  1988 

Tolerance  Committee 
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SECTION  3:  SHAPE  VARIATION  TOLERANCES 


ISSUE 

INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-87  3 ALGORITHMIC  DEFINITION  OF  FEATURES 

2l*‘  August  1987 

Bob  Johnson 

Unresolved 

N/A 

The  features  of  a part  to  which  tolerances  apply  and  which  are  used 
for  datums  need  to  be  algoritlimically  defined  in  order  to  rigorously 
define  the  meaning  of  a tolerance.  A simple  statement  that  a tolerance 
applies  to  a cylindrical  feature  does  not  convey  enough  information; 
a procedure  should  be  defined  to  evaluate  just  what  is  a cylindrical 
feature.  Datum  reference  frames  also  need  to  be  constructed  according 
to  a pre-defined  procedure.  A procedural  approach  would  ensure  tht 
the  feature,  datum  or  tolerance  is  interpreted  exactly  as  intended 


ISSUE  OPTIONS  & EVIDENCE: 

Not  applicable. 

OPTION  PROPOSED;  Not  Applicable 
DECISION:  Not  Applicable 
DECISION  DATE:  Not  Applicable 
ACTION:  Not  Applicable 
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SECTION  3:  SHAPE  VARIATION  TOLERANCES 


ISSUE 

INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-88.1  DERIVED  GEOMETRY 
January  1988 
Mark  Dunn,  James  Blaha 
Preliminary 
86.4 

Issue  86.4  talked  about  he  use  of  off-part  geometry  which  was  derivable 
from  part  geometry  as  the  target  or  the  origin  of  a tolerance.  At  the 
time  a “stub”  was  included  to  introduce  the  idea  into  the  Tolerance 
Model.  The  problem  has  arisen  again  and  must  be  resolved:  how  to 
include  derived  geometry  in  the  model. 


ISSUE  OPTIONS  & EVIDENCE; 

Option  1:  Develop  a construct  which  algorithmically  defines  non-part  geometry  based  upon 
part  geometry. 

Pros; 

Cons; 

Option  2:  Develop  a construct  that  associates  the  components  of  the  shape  model  with  a deriva- 
tion type  designation  and  (optionally)  the  derived  result.  The  derivation  type  desig- 
nation would  reference  an  externally  defined  algorithm  which  will  produce  the  result 
from  the  input  components. 


OPTION  PROPOSED;  Option  2. 

DECISION:  Not  Applicable 
DECISION  DATE: 

ACTION: 
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SECTION  3:  SHAPE  VARIATION  TOLERANCES 


ISSUE 

INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-88.2  TOLERANCING  SUBFACES 

22^*^  Oct  86,  Jan  88 

James  Blaha,  Bob  Parks 

Unresolved 

86.13,  88.6 

Tolerances  may  apply  only  to  a given  subregion  of  a face  rather  than 
the  whole  face.  Also,  these  subregions  may  be  used  as  datums.  Datum 
Targets  (86.13)  pose  a similar  problem.  (Reference  ANSI  V14.5M  ■ 
1982,  pg.  45,  section  4.4.8  for  datums). 

Drafting  must  be  able  to  provide  for  the  representation  of  such  datum 
specifications,  it  must  be  able  to  obtain  the  extent  of  the  surface  being 
specified  as  a datum.  (Figure  104,  pg  45). 


ISSUE  OPTIONS  & EVIDENCE: 


Option  1 
Pros 
Cons 


OPTION  PROPOSED: 

DECISION:  Not  Applicable 
DECISION  DATE: 

ACTION: 


230 


ISO  TC184,  SC4  WGl 


annex  D October  31.  1985 

(Draft  Proposal 

SECTION  3:  SHAPE  VARIATION  TOLERANCES 


ISSUE 

INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-88.3  DATUM  LABELS 
15'^  December  1986 

7 

Unresolved 

N/A 

Is  the  label  attribute  in  datums  simply  a man-readable  piece  of  text’’ 
If  so,  does  it  properly  belong  in  this  model?  If  label  is  a meamngless 
attribute,  then  does  datum  really  have  any  meaning'!’  That  is  not  as 
strange  as  it  sounds,  because  “datum”  is  not  a thing  itself,  but  rather 
a role  played  by  a thing. 


ISSUE  OPTIONS  & EVIDENCE: 


Option  1:  Delete  the  attribute  Label  from  the  Datum  Entity. 
Pros: 

Cons: 

Option  2:  Delete  both  the  attribute  label  and  the  entity  Datum. 
Pros; 

Cons; 

Option  3;  Leave  as-is 


OPTION  PROPOSED: 
EXPLANATION: 

DECISION:  N/A 
DECISION  DATE: 
ACTION: 
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October  31.  1988 


N288 


SECTION  3:  SHAPE  VARIATION  TOLERANCES 


ISSUE: 


INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-88.4  UNCONDITIONED  DATUM  AND  NOT  APPLICA- 
BLE MLSN 
January  1988 
W.C.  Burkett 
unresolved 
N/A 

The  use  of  a material  condition  modifier  (MLS)  in  conditioned  datums 
is  applicable  only  when  the  underlying  shape  element  is  a feature  of 
size.  Otherwise,  it  is  not  applicable  (N).  This  also  includes  the  question 
of  the  default  RES  for  an  unspecified  material  condition  call-out. 


ISSUE  OPTIONS  k EVIDENCE: 

Option  1: 

Pros: 

Cons: 

Option  2: 

OPTION  PROPOSED: 
EXPLANATION: 
DECISION: 
DECISION  DATE: 

ACTION: 
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October  31.  1988 


ISSUE 

INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-88.5  AMBIGUOUS  SIZE  TOLERANCES 

13‘^  January  1988 

Mark  Dunn 

Resolved 

87.2,  88.26,  88.13 

If  a toleranced  feature  has  more  than  one  dimension  subject  to  varia- 
tion is  size,  how  can  multiple  size  tolerances  be  applied  and  interpreted 
unambiguously?  Tliis  problem  is  particularly  apparent  in  an  implicit 
feature  like  a pocket,  which  has  both  a width  and  a length  dimension. 
The  size  tolerance  for  each  would  be  applied  to  the  whole  pocket, 
thereby  causing  the  ambiguity. 


ISSUE  OPTIONS  & EVIDENCE: 


Option  1:  Expand  on  the  idea  of  a Size  dimension  that  will  distinguish  between  different  size 
dimensions  on  a single  feature  and  allow  each  to  be  toleranced  separately.  Size 
Dimension  will  be  categorized  as  either  a Size  Parameter,  which  is  referenced  by 
Implicit  Form  Feature,  and  Size  Characteristics  (from  which  the  value  is  calculated) 
See  details  in  Tolerance  Model  Version  3.0. 

Pros' 

Cons: 

Option  2: 


OPTION  PROPOSED: 
EXPLANATION: 
DECISION: 


DECISION  DATE: 
ACTION: 


Option  1 

The  proposal  for  handling  Size  Dimensions  as  outlined  in  version  3.0  of 
the  Tolerance  Model  solves  the  problem  as  outlined  inthe  issue  and  mets 
with  the  approval  of  the  Form  Feature  Committee. 

lO*''  July  1988 
Tolerance  Committee 
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SECTION  3:  SHAPE  VARIATION  TOLERANCES 


ISSUE 

INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-88.6  GAGE  GEOMETRY  (POINTS.  LINES.  CIRCLES) 
December  1986 

Unresolved 

86.4,  86.13,  88.1,  88.2 

Gage  points  are  often  used  to  dimension/tolerance  slanted  planes  on 
prismatic  parts,  conical  surfaces  on  turned  parts,  etc.  The  essence 
of  a gage  point  is  the  use  of  a basic  dimension  to  specify  the  “to"’ 
(occasionaUy  the  “from”)  location,  which  is  then  constrained  by  the 
tolerance. 


ISSUE  OPTIONS  k EVIDENCE: 


Option  1; 

Pros: 

Cons: 

Option  2: 

OPTION  PROPOSED: 
EXPLANATION: 

DECISION:  N/A 
DECISION  DATE: 
ACTION. 
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SECTION  3:  SHAPE  VARIATION  TOLERANCES 


ISSUE: 

INITIATION  DATE: 
INITIATOR: 
STATUS: 
RELATED  ISSUES: 
DESCRIPTION: 


TOL-88,7  NUMBER  OF  ANGULARITY  AND  PERPENDICU- 
LARITY DATUMS 
22^'^  December  1986,  22^^  July  1987 
Mark  Dunn,  Ed  Klages 
Unresolved 

88.9,  88.24,  88.25,  88.30,  88.46 

Angularity  Tolerance  and  Perpendicularity  Tolerance  currently  allow 
for  up  to  two  datums  to  be  specified.  The  Y14.5  standards  state  that 
each  of  the  tolerances  are  with  respect  to  “a”  datum. 


ISSUE  OPTIONS  k EVIDENCE: 

Option  1: 

Pros: 

Cons: 

Option  2: 

OPTION  PROPOSED: 
EXPLANATION 

DECISION:  N/A 
DECISION  DATE: 

ACTION: 
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SECTION  3:  SHAPE  VARIATION  TOLERANCES 


ISSUE 

INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-88.8  CONCENTRICITY  CYLINDRICAL  ZONE 
9'^  January  1987 
Mark  Dunn 
Unresolved 
88.10,  88,12 

The  cylindrical  .zone  attribute  is  superfluous.  According  to  Y14.5  and 
Foster,  the  tolerance  zone  is  necessarily  cylindrical. 


ISSUE  OPTIONS  & EVIDENCE: 


Option  1 
Pros 
Cons 
Option  2 


OPTION  PROPOSED; 
EXPLANATION: 

DECISION:  N/A 
DECISION  DATE: 
ACTION: 
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SECTI'Cy  3:  SHAPE  VARLATION  TOLERANCES 


ISSUE:  TOL-88.9  CIRCLTAR  RUNOUT.  TOTAL  RUNOUT  DATUMS 


INITIATION  DATE 
INITIATOR: 
STATUS: 
RELATED  ISSUES: 
DESCRIPTION; 


9*^  Januarv  1987,  22'“^  July  1987 
Mark  Dunn,  Ed  Klages 
Unresolved 
88,7,  88,24,  88  25 

Per  Yl4,5  and  Foster,  these  tolerances  may  have  a secondary  datum. 
The  model  only  provides  for  one  dancrrr. 


ISSUE  OPTIONS  & EVIDENCE: 


Option  1: 

Pros: 

Cons; 

Option  2: 

OPTION  PROPOSED; 
EXPLANATION- 

DECISION:  N/A 
DECISION  DATE: 
ACTION: 
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ISSUE; 

INITIATION  DATE: 
INITIATOR: 
STATUS; 
RELATED  ISSUES: 
DESCRIPTION: 


TOL-88.10  CONCENTRICITY  PROJECTED  TOLERANCE 
ZONE 

9'^  January  1988 
Mark  Dunn 
Uaresolved 
88.16,  88.25,  88.42 

Y14.5  says  that  projected  tolerances  zones  may  be  used  with  loca- 
tion and  orientation  tolerances.  The  model  is  consistent  w'ith  tliis  one 
exception  - there  is  no  Projected  attribute  for  the  Concentricity  toler- 
ance. Should  there  be?  Note  that  14.5  does  not  explicitly  say  that  any 
location  or  orientation  tolerance  type  is  susceptible  to  projected  zones, 
nor  did  a brief  search  uncover  an  example  of  a concentricity  tolerance 
with  a projected  zone. 


ISSUE  OPTIONS  & EVIDENCE: 


Option  1 
Pros 
Cons 
Option  2 


OPTION  PROPOSED: 
EXPLANATION: 

DECISION:  N/A 
DECISION  DATE: 
ACTION; 
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SECTION  3:  SHAPE  VARIATION  TOLERANCES 


ISSUE: 


INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-88.11  PROFILE  OF  A LINE,  SURFACE  TOLERANCED 
ENTITY 

January  1988 
Mark  Dunn 
Unresolved 
88.8,  88.10 

One  application  of  these  tolerances  may  apply  to  multiple  faces  or 
edges  as  a set.  Hence  the  Toleranced.Entity  attribute  needs  to  be  a 
list  of  bsts,  rather  than  a simple  List.  More  precisely,  the  Profile  of  a 
Line  Toleranced  Entity  needs  to  be  a list  of  coplanar  edges  or  a list  of 
faces  and  the  Profile  of  a Surface  Toleranced  Entity  needs  to  be  a list 
of  faces. 


ISSUE  OPTIONS  k EVIDENCE: 

Option  1 : 

Pros: 

Cons: 

Option  2: 


OPTION  PROPOSED: 
EXPLANATION: 

DECISION:  N/A 
DECISION  DATE: 
ACTION: 
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SECTION  3:  SHAPE  VARIATION  TOLERANCES 


ISSUE 

INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-88.12  TOLERANCE  ZONE  TYPES 
Janaury  1987 
Mark  Dunn 
Unresolved 
N/A 

The  model  makes  no  provision  for  spherical  Tolerance  zones  The 
Cylindrical-zone  attribute  needs  to  be  replaced  by  an  attribute  having 
one  of  three  values:  parallelipipedic,  cylindrical,  or  spherical. 


ISSUE  OPTIONS  k EVIDENCE: 

Option  1: 

Pros: 

Cons: 

Option  2: 

OPTION  PROPOSED: 
EXPLANATION: 

DECISION:  N A 
DECISION  DATE: 

ACTION: 
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SECTION  3:  SHAPE  VARIATION  TOLERANCES 


ISSUE;  TOL-88.13  TOLERANCES  ON  IMPLICIT  FORM  FEATURES 


INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


13^^  Januaxy  1988,  9‘^  January  1987 

Mark  Duim 

Resolved 

88.5 

While  implicit  form  features  are  shape  defining  components  of  shape 
model,  they  do  not  contain  explicit  pieces  of  geometry  or  other  com- 
ponents to  which  a tolerance  may  be  applied.  If  an  implicit  feature 
contains  a single  size  parameter  (such  as  the  diameter  of  a hole),  then 
the  tolerance  may  be  applied  to  the  whole  feature,  with  the  implica- 
tion that  the  size  tolerance  refers  to  the  single  size  dimension.  If  the 
implicit  feature  contains  more  than  one  size  dimension,  an  ambgiuity 
arises. 


ISSUE  OPTIONS  EVIDENCE; 

Option  1;  Separate  the  notion  of  a size  dimension  from  the  definition  of  implicit  features  and 
allow  size  tolerances  to  be  applied  to  these  explicit  size  dimensions  or  to  explicit 
features  of  size.  See  details  of  Tolerance  Model  Version  3.0. 

Pros; 

Cons; 

Option  2; 


OPTION  PROPOSED;  Option  1 

EXPLANATION;  This  issue  is  essentially  equivalent  to  88.5.  See  the  explanation  in  that 
issue  for  a full  description  of  Size  Dimension  and  Size  Parameters. 
DECISION;  The  categorization  of  Size  Dimension  into  Size  Parameter  and  Size  Char- 
acteristic satisfies  the  requirements  of  this  issue. 

DECISION  DATE;  13"''  July  1988 
ACTION;  Tolerance  Committee 
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SECTION  3:  SHAPE  VARIATION  TOLERANCES 


ISSUE: 

INITIATION  DATE: 
INITIATOR: 
STATUS: 
RELATED  ISSUES: 
DESCRIPTION: 


TOL-88.14  TOLERANCE  QUALIFIERS 
January  1987,  January  1988 
Mark  Dunn,  Bob  Parks 
Unresolved 
88.5 

There  are  a number  of  “qualifiers”  that  may  be  associated  with  tol- 
erance data  and  which  the  tolerances  model  does  not  support.  Ex- 
amples are:  ALL  OVER,  ALL  AROUND,  EACH  ELEMENT,  EACH 
RADIAL  ELEMENT,  FREE  STATE,  AVERAGE  DIAMETER,  FIM 
(FULL  INDICATOR  MOVEMENT).  These  are  all  apparently  sub- 
stantive data.  In  many  cases,  their  message  may  be  deducible  from 
context,  but  this  is  not  always  possible  or  easy. 


ISSUE  OPTIONS  & EVIDENCE: 


Option  1 
Pros 
Cons 
Option  2 


OPTION  PROPOSED: 
EXPLANATION: 

DECISION:  N/A 
DECISION  DATE: 
ACTION: 
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ISSUE 

INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-88.14A  CONSTRAINTS  AND  MODEL  COMPLEXITY 
January  1987 
Mark  Dunn 
Preliminary 
N/A 

If  representation  were  the  only  motivating  consideration,  the  tolerance 
information  model  could  be  very  terse.  (About  10  or  15  entities  would 
suffice.)  The  much  larger  number  of  entities  in  the  model  is  a conse- 
quence of  uisng  the  information  model  to  constrain  the  data.  With 
this  in  mind,  amd  considering  that  only  a fraction  of  “good  practice” 
can  be  enforced  in  the  information  model,  the  following  issue  arises: 
should  extensive  constraining  via  the  information  model  be  attempted'' 
Or  would  it  be  better  to  develop  a simple,  terse  unconstrained  model 
that  focuses  on  representation,  awaiting  (and  agitating  for)  appropri- 
ate constraining  tools? 


ISSUE  OPTIONS  EVIDENCE: 

Option  1: 

Pros: 

Cons: 

Option  2: 

OPTION  PROPOSED: 

EXPLANATION:  a This  issue  has  been  resolved  to  a certain  degree  already.  Extensions 
to  the  Express  language  enabled  the  model  to  be  simplified  by  moving 
the  constraints  from  the  model  (hence,  deleting  entities)  to  Express  stae- 
ments.  This  change  is  reflected  between  versions  2.0  and  2.1  of  the  model. 
(2'''^  October  1987) 

DECISION:  N/A 
DECISION  DATE: 

ACTION: 
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ISSUE 

INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-88.15  TOLERANCES  AND  POLYHEDRIC  MODELS 

U''  April  1987 

Ulrich  Gengenbach 

Resolved 

N/A 

The  Tolerance  Model  has  a very  Boundary  Representation  feeling  to 
it.  How  (or  should)  Tolerances  be  applied  to  Polyhedric  representation 
models? 


ISSUE  OPTIONS  k EVIDENCE: 

Option  1;  The  application  of  tolerances  to  polyhedric  models  depends  upon  the  intended  use 
of  the  model.  If  the  model  is  used  primarily  for  efficient  display  of  an  object  model 
and  is  not  used  for  manufacturing  applications  such  as  NC  and  QA,  then  there  is  no 
need  to  apply  tolerances  to  the  model.  If  this  is  the  case,  then  the  model  should  be 
considered  application  specific,  like  an  FEM  mesh. 

Pros: 

Cons: 

Option  2:  If  there  is  still  a need  to  apply  tolerances  to  this  type  of  model,  then  there  are 
two  probelms  which  must  be  resolved.  The  first  concerns  the  multitude  of  facets 
used  to  approximate  a non-planar  surface.  Although  a polyhedric  model  is  basically 
amenable  to  the  requirements  of  the  Tolerance  Model,  tolerances  are  applied  to  single 
surfaces,  and  the  many  independent  faces  used  in  a polyhedric  approximation  prevent 
this.  If  the  facets  could  be  grouped  to  form  a single  thing,  then  a tolerance  may  be 
applied  to  it.  The  second  problem  is  somewhat  philosophical.  When  a tolerance  is 
applied  to  a non-planar  surface,  it  is  an  approximation  of  the  desired  surface  which  is 
toleranced.  This  poses  a contradiction  because  a tolerance  is  usually  applied  to  the 
theoretically  exact  surface  definition.  The  toleranced  surface  on  an  actual  produced 
part  cannot  be  inspected  from  the  polyhedric  model  because  it  does  not  contain  the 
exact  surface  definition. 

Pros: 

Cons; 


OPTION  PROPOSED: 
EXPLANATION: 


DECISION: 
DECISION  DATE; 
ACTION: 


Option  1 

Option  1 allows  both  models  to  remain  unaffected  by  this  issue,  while 
placing  the  role  of  the  Tolerance  Model  and  Polyhedric  Model  into  per- 
spective. Chosing  Option  2 would  require  some  extensions  to  the  poly- 
hedric model. 

Option  1 
18‘^  May  1987 
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ISSUE 

INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-88  16  PROFILE  TOLERANCE  APPLICATION 

22'^'^  July  1987,  January  1988 

Ed  Klages,  Bob  Parks 

Unresolved 

88.11 

In  addition  to  specifying  whether  the  tolerance  appliation  is  to  be  in- 
side, outside  or  bilateral,  some  provision  must  be  made  for  an  unequally 
disposed  bilateral  tolerance.  See  ANSI  Y14.5  - 1982  6.5.1  (b). 


ISSUE  OPTIONS  &:  EVIDENCE: 


Option  1 
Pros 
Cons 
Option  2 


OPTION  PROPOSED: 
EXPLANATION: 

DECISION:  N A 
DECISION  DATE: 
ACTION: 
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ISSUE 

INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-88,17  DATUM  CONSTRAINTS 
14‘^  October  1987 
Bob  Parks 
Unresolved 
86.16 

Primary,  Secondary  and  Tertiary  datums  must  be  exclusive  of  each 
other  (primary  and  secondary  cannot  be  the  same,  primary  and  ter- 
tiary must  be  different,  etc.  ).  Also,  where  multiple  datums  are  speci- 
fied for  a particular  geometric  tolerance  they  should  be  sufficient  to 
establish  a datum  reference  frame  of  three  mutually  perpendicular 
planes. 


ISSUE  OPTIONS  & EVIDENCE: 

Option  1: 

Pros: 

Cons: 

Option  2: 


OPTION  PROPOSED: 
EXPLANATION: 

DECISION:  N/A 
DECISION  DATE: 
ACTION: 
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ISSUE 

INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-88.18  TOLERANCE  EXISTANCE  FOR  DRAFTING 

14‘^  October  1987 

Bob  Parks 

Preliminary 

N/A 

If  a product  model  is  not  complete  (i.e.  lacking  a particular  tolerance 
with  a datum  specification),  how  will  drafting  be  allowed  to  deal  with 
the  product  data  (augmentation)? 


ISSUE  OPTIONS  & EVIDENCE: 

Option  1:  The  expansion  of  the  “dimension”  concept  in  the  Tolerance  Model  Version  3 0 may 
resolve  this  concern. 

Pros; 

Cons: 

Option  2: 

OPTION  PROPOSED:  Option  1 
EXPLANATION: 

DECISION:  N/A 
DECISION  DATE: 

ACTION: 
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ISSUE: 
INITIATION  DATE: 
INITIATOR: 
STATUS: 
RELATED  ISSUES: 
DESCRIPTION: 


TOL-88.19  TOLERANCE  NAMES 

23’’'^  December  1987 

Mark  Dunn 

Unresolved 

N/A 

The  names  of  the  tolerance  entities  are  not  sufhcientlv  descriptive  in 
that  the  word  “tolerance”  is  absent  This  is  particularly  worrisome  for 
entities  LOCATION,  ANGLE,  SIZE  , and  POSITION,  whose  names 
suggest  nominal  shape  concepts. 


ISSUE  OPTIONS  k EVIDENCE: 

Option  1:  Add  the  word  “tolerance”  to  the  names  of  the  tolerance  entities  so  that,  for  example, 
entity  404  would  be  ANGLE  TOLERANCE. 

Pros: 

Cons: 

Option  2: 


OPTION  PROPOSED: 
EXPLANATION: 

DECISION:  N/A 
DECISION  DATE: 
ACTION: 
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ISSUE 

INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-88.20  LOCATION  TOLERANCE  DIMENSION 

23’’'^  December  1987 

Mark  Dunn 

Preliminary 

86.11,  87.2,  88.26 

The  information  in  and  associated  with  the  LOCATION/ 403  enfitv 
is  not  adequate  to  describe  the  dimension  being  toleranced.  (The 
SIZE/405  and  probably  ANGLE/404  suffer  from  the  same  problem.) 
The  original  and  basic  idea  of  the  model  is  that  location  tolerances 
apply  to  the  dimensions  (nominal  distances)  between  pairs  of  "physi- 
cal” topological/geometric  entities.  How'ever,  this  is  sufficient  only  for 
the  simple  cases  where  there  is  a constant  distance  between  the  origin 
and  target  (toleranced  entity),  e.g.  parallel  planes,  concentric  cylin- 
ders. There  are  many  cases  that  are  not  so  simple  either  because  the 
the  origin  or  the  target  is  non-physical  or  because  the  Brep-ish  model 
contains  no  pair  of  parallel  topological / geometric  entities  to  serve  as 
the  origin  and  target. 

The  following  data  were  included  in  the  LOCATION  403  entity  to 
provide  the  specificity  needed  for  non-simple  cases:  Ongin.Loc,  a point 
nominally  on  the  origin  of  the  toleranced  dimension;  Tol  Ent  loc,  a 
point  nominally  on  the  target  of  the  toleranced  dimension;  Path,  the 
nominal  direction  of  measurement  of  the  toleranced  dimension.  It  is 
felt  that  even  with  this  information,  the  model  is  unsatisfactory.  On 
any  particular  piece,  the  points  will  be  inside  the  material  or  in  the 
air  and  the  path  (direction)  will  deviate  from  the  nominal.  The  origin 
and  target  of  the  dimension  of  interest,  as  well  as  the  direction  of 
measurement,  can  only  be  determined  from  physical  measurement  and 
a knowledge  of  the  intended  dimension.  Thus,  the  specification  of 
the  intended  measurement  must  be  explicit  in  or  deriveable  from  the 
modeled  information. 

NOTE:  This  problem  description  has  been  superceded  and  rendered 
obsolete  by  the  work  of  the  Tolerance  Committee  as  reported  in  the 
report  dated  25‘^  March  1988  and  Version  3.0  of  the  Tolerance  Model. 
The  concept  of  dimension  has  been  expanded  upon,  hopefully  rectifying 
the  problem  spelled  out  above.  The  details  of  the  Technical  Report 
have  been  incorporated  into  a new  version  of  the  Tolerance  Model, 
version  3.0. 


ISSUE  OPTIONS  & EVIDENCE: 

Option  1:  Expand  on  the  “dimension”  concept  for  Location,  Size  and  Angle  tolerances.  See 
details  in  the  Tolerance  Model  Version  3.0. 


Pros: 
Cons: 
Option  2: 
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ACTION: 


ANNEX  D October  31.  1988 
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Option  1 

This  issue  is  no  longer  valid  because  the  new  approach  for  determining  the 
dimensional  value  for  a coordinate  dimension  requires  that  the  tolerance 
origin  and  tolerance  target  be  parallel  to  one  another. 

This  issue  is  considered  resolved  by  the  committee. 

13‘''  July  1988 
Tolerance  Committee 
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ISSUE 

INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-88.21  TABULATED  TOLERANCES 

Janaury  1988 

Bob  Parks 

Unresolved 

N/A 

Tabulated  Tolerances  for  a family  of  parts  cannot  be  accommodated 
in  the  model. 


ISSUE  OPTIONS  & EVIDENCE: 

Option  1:  Make  the  tolerance  attribute  of  the  Geometric  Tolerance  entity  a selection  of  type 
number  or  tolerance-id,  where  the  tolerance-id  corresponds  to  a table  of  values. 

Pros: 

Cons; 

Option  2: 


OPTION  PROPOSED: 
EXPLANATION: 

DECISION:  N/A 
DECISION  DATE: 
ACTION: 
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ISSUE 

INITIATION  DATE 
INITUTOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-88  22  TEMPORARY  AND  PERMANENT  DATUMS 
Janaury  1988 
Bob  Parks 
Unresolved 
86.6 

Since  temporary  datums  may  be  established  for  machining  operations 
that  create  permanent  datums,  should  this  distinction  be  accomodated 
in  the  modeU  (reference  ANSI  Y14.5M  1982,  section  4.2.1,  page36  ) 


ISSUE  OPTIONS  & EVIDENCE: 

Option  1: 

Pros: 

Cons: 

Option  2: 


OPTION  PROPOSED: 
E'PLANATION: 

DECISION:  n;a 
DECISION  DATE: 
ACTION: 
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INITIATION  DATE 
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RELATED  ISSUES 
DESCRIPTION 


TOL-88.23  UNIDIRECTIONAL  AND  BI-DIRECTION aL  DI- 
MENSIONS 

February  1988 
Mark  Dunn 
Preliminary 
88.29 

It  is  necessary  to  distinguish  between  bi-directional  (undirected,  “be- 
tween”) location  dimensions  and  unidirectional  (directed,  “from/to”). 


ISSUE  OPTIONS  & EVIDENCE: 


Option  1:  Add  a flag  to  the  Location  Dimension  to  distinguish  between  directed  and  bi- 
directional dimensions.  See  Coordinate  Dimensions  in  Version  3 0 of  the  Tolerance 
Model. 

Pros: 

Cons: 

Option  2: 


OPTION  PROPOSED: 
EXPLANATION: 


DECISION: 
DECISION  DATE: 
ACTION: 


Option  1 

The  addition  of  a simple  flag,  as  reflected  in  version  3 0 of  the  Tolerance 
Model  resolves  this  problem.  The  same  issue,  however,  applies  to  the 
Related  Angle  Dimension  (but  is  recorded  as  a separate  issue. 

This  issue  is  resolved  with  the  noted  change. 

13‘^  July  1988 
Tolerance  Committee 
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ISSUE 

INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-88.24  CO-DATUMS 
February  1988 
Mark  Dunn 
Unresolved 

88.7,  88.9,  88.25,  88.46 

The  model  only  provides  for  co-datums  for  circular  runout,  concentric- 
ity, and  total  runout.  It  is  possible  that  co-datums  may  be  specified 
elsewhere. 


ISSUE  OPTIONS  ic  EVIDENCE: 


Option  1 
Pros 
Cons 
Option  2 


OPTION  PROPOSED: 
EXPLANATION: 

DECISION:  N'A 
DECISION  DATE: 
ACTION: 


i 


N288 


254 


ISO  TC184  SC4/ WGl 


annex  D 

(Draft  P roposal 


October  3 1 , 1988 


N288 


SECTION  3:  SHAPE  VARIATION  TOLERANCES 


ISSUE 

INITIATION  DATE 
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RELATED  ISSUES 
DESCRIPTION 


TOL-88.25  PRFOILE  OF  A LINE  - NUMBER  OF  DATUMS 
15‘^  February  1988 
Mark  Dunn 
Unresolved 

88.7,  88.9,  88.24,  88.11,  88.16 

Is  a tertiary  datum  possible  for  a profile  of  a line  tolerance'’  It  seems 
that  a third  datum  may  be  illogical  in  a 2-D  tolerance 


ISSUE  OPTIONS  & EVIDENCE: 


Option  1 
Pros 
Cons 
Option  2 


OPTION  PROPOSED: 
EXPLANATION: 

DECISION:  N/A 

DECISION  DATE: 
ACTION: 
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ISSUE: 

INITIATION  DATE; 
INITIATOR; 
STATUS: 
RELATED  ISSUES: 
DESCRIPTION; 


TOL-88.26  DEFINITION  OF  “DIMENSION” 

February  1988 
Mark  Duim 
Preliminary 
86.1,  87.2,  86.11,  88.20 

There  are  two  concepts  in  the  term  “dimension”:  a measurement  on 
a product  and  the  value  of  that  measurement.  The  latter  can  be  de- 
termined (nominally)  from  a model  if  the  measurement  is  known.  The 
tolerance  model  must  provide  for  describing  the  measurement. 


ISSUE  OPTIONS  Sc  EVIDENCE: 


Option  1:  The  components  which  make  up  a dimension  should  be  separated  and  a clear  ex- 
planation of  what  a “dimension”  is  should  become  part  of  the  model.  A possible 
approach  for  doing  this  was  reported  in  a technical  report  dated  25‘^  March  1988 
and  in  version  3.0  of  the  Tolerance  Model  (8‘^  July  1988). 

Pros: 

Cons: 

Option  2: 


OPTION  PROPOSED:  Option  1 

EXPLANATION:  The  expansion  of  the  idea  of  “dimension”  within  the  Tolerance  Model 
will  eliminate  much  of  the  ambiguity  in  the  relationship  of  “dimensions” 
to  the  tolerances. 

DECISION:  The  definition  of  dimension  within  version  3.0  of  the  Tolerance  Model 
resolves  this  issue. 

DECISION  DATE:  13‘''  July  1988 
ACTION;  Tolerance  Committee 
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ISSUE:  TOL-88.27  MINIMUM  AND  MAXIMUM  DIMENSION  VALUE 


INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


15'^  February  1988 
Kim  Perlotto 
Unresolved 
88.36 

Sometimes  a minimum  value  is  given,  with  no  maximum  and  vice- 
versa.  The  model  can  stretched  to  cover  maximum,  but  not  rrunimums 


ISSUE  OPTIONS  & EVIDENCE: 

Option  1: 

Pros: 

Cons: 

Option  2: 

OPTION  PROPOSED: 
EXPLANATION: 

DECISION:  N'A 

DECISION  DATE: 

ACTION: 
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DESCRIPTION 


TOL-88.28  DIAMETER  VS.  RADIUS  SIZE  TOLER \NCE 
July  1988 
Mark  Dunn 
Preliminary 
88.5 

A Size  Tolerance  may  be  applied  to  a diametrical  or  a radial  dimension, 
but  there  is  no  way  to  indicate  this  distinction.  It  is  important  to  make 
this  distinction  because  the  tolerance  zone  for  a radial  tolerance  is  twice 
the  size  of  a tolerance  zone  for  a diameter  tolerance  of  equal  value. 


ISSUE  OPTIONS  k EVIDENCE: 

Option  1:  The  addition  of  a simple  flag  within  the  Size  Dimension  will  indicate  whether  the 
tolerance  applies  to  the  radial  value  or  diameter  value. 

Pros: 

Cons: 

Option  2: 

OPTION  PROPOSED: 

EXPLANATION: 

DECISION:  N/A 

DECISION  DATE: 

ACTION: 
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ISSUE: 

INITIATION  DATE: 
INITIATOR: 
STATUS: 
RELATED  ISSUES: 
DESCRIPTION: 


TOL-88.29  UNI-DIRECTIONAL  vs  BI  DIRECTION AL  AN- 
GLE DIMENSION 
13'^  July  1988 
Mark  Dunn 
PreUrrunary 
88.23 

As  described  in  88.23,  a coordinate  dimension  may  uni-directional  (i  e 
measured  in  a specified  direction)  or  may  be  bi-directional  (i  e.  direc- 
tion of  measurement  unimportant.)  The  issue  described  in  88  23  as 
applied  to  Location  dimensions  also  applies  to  Related  Angle  Dimen- 
sions and  may  be  similarly  resolved. 


ISSUE  OPTIONS  k EVIDENCE: 

Option  1:  Include  a binary  flag  within  the  Related  Angle  Dimension  that  indicated  whether  the 
measurement  is  directed  or  undirected. 

Pros:  Consistent  with  Location  Dimension. 

Cons: 

Option  2: 


OPTION  PROPOSED:  Option  1 
EXPLANATION: 
DECISION: 
DECISION  DATE: 

ACTION: 
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ISSUE: 

INITIATION  DATE: 
INITIATOR 
STATUS: 
RELATED  ISSUES: 
DESCRIPTION: 


TOL-88.30  NUMBER  OF  DATUMS  FOR  ANGULARITY. 

PARALLELISM,  PERPENDICULARY 
13‘''  July  1988 

John  Yanney  (GD-FW),  JNC-Hashimoto 

Unresolved 

88.7,  88.46 

Angularity,  Parallelism,  and  Perpendicularity  tolerances  do  not  allow 
for  the  specification  of  three  datums.  Three  datums  may  be  specified 
to  form  a Datum  Reference  Frame  for  each  tolerance. 


ISSUE  OPTIONS  A:  EVIDENCE: 

Option  1: 

Pros: 

Cons: 

Option  2: 

OPTION  PROPOSED: 
EXPLANATION: 
DECISION: 
DECISION  DATE: 

ACTION: 
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ISSUE: 


INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-88  31  RELATIONSHIP  BETWEEN  COORDINATE  DI- 
MENSION AND  COORDINATE  TOLERANCE 
13‘^  July  1988 
Mark  Dunn 
Unresolved 
N/A 

The  relationshjp  between  the  coordinate  tolerance  entities  and  the  di- 
mension entities  are  backwards.  The  dimensional  entity  should  be  the 
parent,  the  tolerance  entity  the  dependent  child  (via  a “Z”  relation- 
ship). The  dimension  is  the  information  of  first  instance  without  which 
the  tolerance  is  meaningless;  the  tolerance  is  subordinate. 


ISSUE  OPTIONS  k EVIDENCE: 


Option  1:  Flip  the  relationship  causing  the  Dimension  to  be  the  Parent  and  Tolerance  the  child 
in  the  relationship. 

Pros: 

Cons: 

Option  2:  Leave  as  is.  with  Tolerance  the  Parent  and  Dimension  the  Child. 


OPTION  PROPOSED: 
EXPLANATION: 
DECISION: 
DECISION  DATE: 
ACTION: 
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ISSUE: 


INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-88.32  D &:  T SHAPE  ELEMENT  AND  FORM  FEATURE 

CATEGORIZATION 

13‘^  July  1988 

Mark  Dunn 

Preliminary 

N/A 

The  work  of  the  Integration  Committee  has  resulted  m some  specified 
relationships  between  shape  elements,  their  representations  and  Form 
Features.  The  Tolerance  Model,  however,  takes  some  liberties  in  the 
inclusion  of  these  concepts.  In  order  to  keep  the  work  in  sync,  the 
model  should  be  changed  to  correspond  to  the  Integration  Work.  This 
IS  basically  an  IDEFlX  modelimg  problem. 


ISSUE  OPTIONS  k EVIDENCE: 


Option  1:  Change  “Shape  Element”  within  the  Tolerance  Model  to  “DT  Shape  Element”,  cat- 
egorize it  according  the  needs  of  the  Tolerance  Model  and  establish  relationships 
between  the  categories  and  the  corresponding  Shape  Element  from  the  Integration 
Model.  Also  change  Form  Feature  to  BT  Form  Feature  and  relate  it  to  Form 

Pros: 

Cons: 

Option  2: 

OPTION  PROPOSED.  Option  1.  See  \'ersion  3 1 of  the  Tolerance  Model  for  details  (Entity  300, 

DT-Feature). 

EXPLANATION: 

DECISION: 

DECISION  DATE: 

ACTION: 
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ISSUE 

INITIATIOxN  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-88.33  SYMMETRY  TOLERANCE 

13‘^  July,  1988 

JNC  - Dr.  Hashimoto 

Unresolved 

N/A 

Both  the  ISO  and  ANSI  standards  specify  a geometric  tolerance  called 
Symmetry.  This  tolerance  is  not  included  in  the  Tolerance  Model,  but 
should  be. 


ISSUE  OPTIONS  EVIDENCE: 


Option  1; 
Pros: 
Cons: 

Option  2: 


Include  a geometric  Symmetry  Tolerance 
Will  correspond  with  the  current  specification. 

Was  under  consideration  for  deletion  from  Standard  (at  least  the  ANSI  version  of 
the  standard).  The  current  status  of  this  question  is  unknown. 


OPTION  PROPOSED: 
EXPLANATION: 
DECISION: 
DECISION  DATE: 
ACTION: 
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ISSUE 

INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-88.34  ARRANGEMENT  OF  ENTITY  DEFINITIONS 
July  1988 

JNC  - Dr.  Hashimoto 

Unresolved 

N/A 

The  Tolerance  Entities  are  currently  arranged  alphabetically  within 
the  model.  They  should  be  rearranged  categorically  according  to  the 
standards  (Tolerances  of  Form,  Orientation,  Runout,  Profile.) 


ISSUE  OPTIONS  & EVIDENCE: 

Option  1: 

Pros: 

Cons: 

Option  2: 


OPTION  PROPOSED 
EXPLANATION: 
DECISION: 
DECISION  DATE: 
ACTION: 


N2  8 8 


264 


ISO  TC1«4  5C4  ’OGl  ANNEX  D 

(Draft  Proposal 

SECTION  3:  SHAPE  VARIATION  TOLERANCES 


ISSUE: 

INITIATION  DATE: 
INITIATOR: 
STATUS: 
RELATED  ISSUES: 
DESCRIPTION: 


TOL-88.35  START  POINT  FOR  PROJECTED  TOLERANCE 
ZONE 

13^'’  July  1988 

JNC  - Dr.  Hashimoto 

Unresolved 

N/A 

Projected  Tolerance  Zone  is  currently  defined  in  terms  of  direction  and 
extent  (length).  A start  point  for  the  zone  should  also  be  included  as 
part  of  the  definition. 


ISSUE  OPTIONS  & EVIDENCE: 


Option  1: 
Pros: 
Cons: 


Option  2: 


Include  a start  point  with  the  PTZ  definition 
Would  more  clearly  define  the  projected  zone. 

Because  a tolerance  can  be  apphed  to  more  than  one  target  at  a time  (e  g.  a Position 
Tolerance  can  be  applied  to  a set  of  Holes.)  the  start  point  for  a Projected  Tolerance 
Zone  for  a single  tolerance  may  not  be  unique  (i.e.  there  may  be  many  start  points, 
one  for  each  target  (e.g.  hole),  each  with  the  same  direction  and  extent.) 

Include  a set  of  start  points  within  the  PTZ  definition. 


OPTION  PROPOSED: 
EXPLANATION: 
DECISION- 
DECISION  DATE: 
ACTION: 
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ISSUE: 


IMTI.MION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-88.36  COORDINATE  TOLERANCE  RANGE  APPLICA- 
TIONS 

13'^  July  1988 

JNC  - Dr.  Hashimoto 

Unresolved 

88.27 

The  Coordinate  Tolerance  Range  (plus/minus)  for  the  value  of  a 
measurement  currently  restricted  to  a positive  or  zero  value  for  the 
Plus-Tolerance,  a positive  or  zero  value  for  the  Minus. Tolerance,  and 
Plus  Tol  + Minus _Tol  not  equal  to  zero.  There  are  a number  of  addi- 
tional cases,  examples  of  which  are  in  the  ISO  and  ANSI  Standards, 
that  are  not  accommodated  by  this  approach.  These  include: 

1)  both  the  upper  bound  and  lower  bound  of  the  range  have  the  same 
sign  (e  g.  +0.010,  +0.005;  -0.02,  -0.06); 

2)  limit  dimensioning  (i.e.  specification  of  maximum/minimum  values 
or  a single  maximum  or  mimmum  value  for  the  dimension); 

3)  the  use  of  ISO  symbols  for  tolerances  (e  g.  0 12H7/h6). 


ISSUE  OPT  ONS  k EVIDENCE: 


Option  1: 
Pros: 
Cons: 
Option  2: 


OPTION  P vOPOSED: 
EXPL  ^NATION 
DECISION: 
DECISION  DATE: 
ACTION: 
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ISSUE: 

INITIATION  DATE: 
INITIATOR: 
STATUS: 
RELATED  ISSUES: 
DESCRJPTION: 


TOL-88  37  MATERIAL  CONDITION  MODIFIER  I OR  PRO- 
FILE OF  LINE  'SURFACE 
13'^  July  1988 
JNC  - Dr.  Hashimoto 
Unresolved 
N/A 

The  Profile  of  a Line  and  Profile  of  a Surface  Tolerance  use  Conditioned 
Datums,  yet  do  not  also  have  a Material  Condition  Modifier  (MCM) 
attribute.  Both  tolerances  should  have  a MCM  as  an  attribute. 


ISSUE  OPTIONS  &:  EVIDENCE: 


Option  1: 
Pros: 
Cons: 
Option  2: 


OPTION  PROPOSED: 
EXPLANATION: 
DECISION: 
DECISION  DATE: 
ACTION: 
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ISSUE. 

INITIATION  DATE; 
INITIATOR: 
STATUS: 
RELATED  ISSUES; 
DESCRIPTION: 


TOL-88.38  LOCATION  DIMENSION  VALUE 

13'^  July  1988 

JNC  - Dr.  Hashimoto 

Unresolved 

N/A 

A nominal  dimension  value  is  necessary  to  define  the  Location  Dimen- 
sion. A value  is  included  for  both  the  Size  and  Angle  Dimensions,  and 
should  be  included  in  Location. 


ISSUE  OPTIONS  k EVIDENCE: 

Option  1;  Add  an  attribute  for  the  Nominal  Location  Dimension  V'alue 
Pros: 

Cons: 

Option  2; 


OPTION  PROPOSED: 
EXPLANATION: 
DECISION: 
DECISION  DATE: 
ACTION: 
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SECTION  3:  SHAPE  VARIATION  TOLERANCES 


ISSUE: 

INITIATION  DATE: 
INITIATOR: 
STATUS: 
RELATED  ISSUES: 
DESCRIPTION: 


TOL-88.39  TARGET  OF  POSITION,  CONCENTRICITY,  CIR- 
CULAR RUNOUT 
13*''  July  1988 
JNC  - Dr.  Hashimoto 
Unresolved 
N/A 

Position,  Concentricity  and  Circular  Runout  tolerances  can  apply 
equally  to  Features  of  Size,  Area  and  Seams.  Currently,  each  toler- 
ance can  apply  to  only  a subset  of  these  things. 


ISSUE  OPTIONS  & EVIDENCE: 

Option  1.  Change  the  definition  of  each  entity  to  aUow  it  reference  each  type  of  target:  Feature 
of  Size,  Area  and  Seam. 

Pros: 

Cons: 

Option  2: 


OPTION  PROPOSED 
EXPLANATION: 
DECISION: 
DECISION  DATE: 
ACTION: 
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ISSUE: 


INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-88  40  PER  UNIT  LENGTH  FOR  PARALLELISM,  PER- 
PENDICULARY,  ANGULARITY 
July  1988 

JNC  - Dr.  Hashimoto 

Unresolved 

N/A 

A Per  Unit  Length  specification  is  valid  not  only  with  the  context  of  a 
Straightness  Tolerance,  but  also  within  Parallelism,  Perpendicularitv 
and  Angularity  Tolerances.  An  attribute  should  be  added  to  each 
entity  to  account  for  this. 


ISSUE  OPTIONS  k EVIDENCE: 

Option  1:  Add  an  attribute  “Per  Unit  Length”  to  the  Parallelism,  Perpendicularity,  and  Angu- 
larity tolerances. 

Pros: 

Cons: 

Option  2: 


OPTION  PROPOSED: 
EXPLANATION- 
DECISION: 
DECISION  DATE: 
ACTION: 


270 


ISO  TC184  SC4,  WGl 


ANNEX  D 
(Draft  Proposal 

SECTION  3:  SHAPE  VARIATION  TOLERANCES 


N288 

October  31,  1988 


ISSUE: 


INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-88  41  MATERIAL  CONDITION  MODIFIER  FOR 

CONCENTRJCITY,  CIRCULARITY,  CYLINDRICITY,  CIRCULAR 

AND  TOTAL  RUNOUT  TOLERANCES 

13‘^  July  1988 

JNC  - Dr.  Hashimoto 

Unresolved 

N/A 

The  Material  Condition  Modifier  can  be  specified  for  Concentricitym, 
Circularity,  Cylindricity,  Circular  and  Total  Runout  Tolerances.  These 
entities  should  be  modified  to  reflect  this  fact. 


ISSUE  OPTIONS  t EVIDENCE: 


Option  1: 

Pros: 

Cons: 

Option  2: 

OPTION  PROPOSED: 
EXPLANATION: 
DECISION: 
DECISION  DATE: 
ACTION: 
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ISSUE; 

INITIATION  DATE: 
INITIATOR: 
STATUS: 
RELATED  ISSUES: 
DESCRIPTION: 


TOL-88.42  PROJECT  TOLERANCE  ZONE  FOR  CONCEN- 
TRICITY 
July  1988 

JNC  - Dr.  Hashimoto 

Unresolved 

88.10 

The  purpose  of  the  Projected  Tolerance  Zone  is  to  increase  the  size 
the  tolerance  zone  defined  by  a tolerance  beyond  the  limits  of  the 
feature  being  toleranced.  Given  it’s  applicablility  to  Position,  Angu- 
larity, Parallelism,  and  Perpendicularity,  it  would  also  seem  applicable 
to  Concentricity. 


ISSUE  OPTIONS  k EVIDENCE: 

Option  1: 

Pros: 

Cons: 

Option  2: 

OPTION  PROPOSED: 
EXPLANATION: 
DECISION: 
DECISION  DATE: 

ACTION: 


N288 


272 


(Draft  Proposal 


N288 


SECTION  3:  SHAPE  VARIATION  TOLERANCES 


TOL-88  43  APPLICATION 

DIRECTION  FOR  PARALLELISM,  PERPENDICULARITY  , PO- 
SITION, CIRCULAR  RUNOUT,  AND  TOTAL  RUNOUT 
13‘^  July  1988 
JNC  - Dr.  Hashimoto 
Unresolved 
N/A 

Straightness  Tolerance  can  be  applied  to  a surface  in  a specified  di- 
rection (e.g.  on  a cylinder,  surface  elements  parallel  to  the  axis  can 
be  toleranced  with  a straightness  tolerance.)  In  a similar  fashion,  a 
direction  may  be  used  to  specify  the  application  of  Parallelism,  Per- 
pendicularity, Position,  Circular  Runout  and  Total  Runout. 

ISSUE  OPTIONS  EVIDENCE: 

Option  1:  Include  a direction  specification  in  the  identified  entities. 

Pros: 

Cons: 

Option  2: 

OPTION  PROPOSED: 

EXPLANATION: 

DECISION: 

DECISION  DATE: 

ACTION: 


ISSUE: 


INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 
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ISSUE: 

INITIATION  DATE: 
INITIATOR: 
STATUS: 
RELATED  ISSUES: 
DESCRIPTION: 


TOL-88.44  DEFAULT  TOLERANCES  FOR  OTHER  TOLER 
ANCES. 

13*''  July  1988 
JNC  - Dr.  Hashimoto 
Unresolved 
86.8 

A default  tolerance  is  currently  only  allowed  for  Profile  of  a Surface 
Tolerance.  All  tolerance  entities  should  be  allowed  to  be  specified  as  a 
default. 


ISSUE  OPTIONS  &:  EVIDENCE: 


Option  1 
Pros 
Cons 
Option  2 


OPTION  PROPOSED: 
EXPLANATION: 
DECISION: 
DECISION  DATE: 
ACTION: 
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ISSUE: 

INITIATION  DATE: 
INITIATOR: 
STATUS: 
RELATED  ISSUES: 
DESCRIPTION: 


TOL-88  45  APPLICATION  OF  TOTAL  AND  CIRCULAR 

RUNOUT  TOLERANCE 
July  1988 

JNC  - Dr.  Hashimoto 

Unresolved 

N/A 

Application  of  the  tolerance  is  currently  specified  in  Profile  Line  Toler- 
ance and  Profile  Surface  Tolerance.  Isn’t  it  necessary  that  Application 
should  also  be  specified  in  Circular  Runout  and  Total  Runout  Toler- 
autce"^ 


ISSUE  OPTIONS  Sc  EVIDENCE: 


Option  1 
Pros 
Cons 
Option  2 


OPTION  PROPOSED: 
EXPLANATION: 
DECISION: 
DECISION  DATE: 
ACTION: 
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ISSUE: 


INITIATION  DATE 
INITIATOR 
STATUS 
RELATED  ISSUES 
DESCRIPTION 


TOL-88.46  SPECIFICATION  OF  DATUMS  FOR  PERPEN- 
DICULARITY, PARALLELISM  AND  ANGULAR  TOLERANCE. 
13‘^  July  1988 
JNC  - Dr.  Hashimoto 
Unresolved 
88.7,  88.24,  88.30 

With  respect  to  Datums,  the  Angularity,  Parallelism  and  Perpendicu- 
larity tolerances  should  be  modified  as  follows: 

Descriptions  in  Version  3.0 


In  Parallelism  tolerance  (412),  Primary  Datum  can  be  specified. 


In  Perepndicularity  Tolerance  (413),  Primary  and  Secondary  Datums 
can  be  specified. 


In  Angularity  (406),  Primary,  Secondary  and  Tertiary  Datums  can 
be  specified. 


Amended  version: 


In  Parallelism  Tolerance  and  in  Perpendicularity  Tolerance,  Pri- 
mary Datum,  Co-primary  Datum,  Secondary  Datum,  and  Co- 
secondary datum  can  be  specified. 

In  Angularity  Tolerance,  Primary  Datum  and  Co-primary  datum  can 
be  specified. 


ISSUE  OPTIONS  k EVIDENCE: 

Option  1: 

Pros: 

Cons: 

Option  2: 

OPTION  PROPOSED: 
EXPLANATION; 
DECISION: 
DECISION  DATE; 

ACTION: 
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3.7  Change  History 

Model  changes  reflected  in  this  section  outline  the  difTerences  between  the  PDES  Tolerance  Model 
Version  (unnumbered)  dated  September  1986  and  Version  1.0  dated  January  1987. 

1.  Tolerances  are  often  to/from  off-part  geometry  which  is  derived  from  product  geometry  (e.g 
centerlines).  An  Entity  called  DERIVED  GEOMETRY  was  added  to  the  model. 

2.  The  Angle  Tolerance  was  considered  confusing  and  imprecise.  Changes  were  made  remedy 
this  problem. 

3.  References  to  BASIC  dimensions  have  been  removed  from  the  model.  The  geometric,  product 
model  itself  is  considered  BASIC. 

4.  Default  tolerances  wiU  be  handled  by  adding  a flag  to  the  Profile  of  a Surface  tolerance  to 
indicate  a default  condition. 

5.  The  relationship  between  Size  Feature,  Feature.of-Size,  and  Form  Feature  has  been  clarified. 

6.  Material  Condition  Modifiers  (MMC,  LMC,  RFS)  apply  only  to  “features”  subject  to  variation 
in  size  (i.e.  features-of.size).  Changes  to  reflect  this  have  been  made. 

7.  There  was  some  confusion  over  the  intent  and  meaning  of  the  coordinates  associated  with 
the  Location  Tolerance.  Some  minor  changes  have  been  made  to  reduce  the  probability  of 
problems,  but  further  work  in  necessary. 

Model  changes  reflected  in  the  following  section  outline  the  differences  between  the  PDES 
Tolerance  Model  Version  1.0  dated  9‘^  January  1987  and  Version  2.0  dated  27‘^  March  1987.  These 
changes  were  prompted  by  the  release  of  the  PDES  Initial  Testing  Draft  amd  bring  this  model  into 
correspondence  with  the  Testing  Draft.  There  have  been  no  changes  in  technical  content,  but  rather 
a conversion  to  bring  this  model  in  line  with  the  released  Testing  Draft.  All  entities  and  definitions 
within  the  model  are  entities  which  appear  in  the  Testing  Draft. 

1.  The  explanation  on  Model  Content  in  the  Assumptions  section  has  been  modified  to  reflect 
the  release  of  the  Testing  Draft. 

2.  The  Entity  Pool  section  has  been  modified  so  that  the  alphabetic  and  numeric  listing  of  the 
entities  each  fall  entirely  on  a single  page. 

3.  Geometry(lOO)  was  renamed  Wire-Frame-Geometry(lOO)  and  the  diagram  changed  to  reflect 
the  Testing  Draft. 

4.  Unit. Vector(  101)  was  renamed  Direction(lOl)  to  bring  it  in  line  with  the  Testing  Draft. 

5.  Point-Vector(102)  was  renamed  Projected. Tolerance. Zone  and  changed  to  reflect  the  contents 
of  the  Geometry  model.  The  concept  of  Vector  and  Point  Vector  did  not  exist  in  the  Geometry 
Model,  so  rather  than  create  them,  an  entity  was  defined  (Projected.Tolerance.Zone)  that 
contained  the  same  functionality  and  had  a clearly  defined  usage  and  intent. 
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6.  Vector(103)  was  deleted  as  unnecessary  (see  item  5) 

7.  Subtypes  of  Curve(106)  were  deleted  as  superfluous. 

8.  Coordinate(107)  was  renamed  Cartesian-Point. 

9.  Topology(200)  was  renamed  Shape-Brep(200). 

10.  Entities  204-214  were  named  Face  or  Edge  with  a geometric  adjective  modifying  the  meaning 
were  deleted.  The  purpose  of  these  entities  were  to  constraint  the  types  of  entities  to  which 
a certain  tolerance  may  apply.  These  constraints  have  been  incorporated  into  an  Express 
WHERE  clause  in  the  entity’s  definition.  This  made  these  entities  imnnecessary. 

11.  References  to  Form  Features  have  been  removed  since  they  are  not  pertinent  to  the  definition 
of  the  Tolerance  Model. 

12.  Tolerance(400)  was  renamed  Shape. Tolerance(400). 

The  changes  to  the  model  outlined  in  the  following  section  represent  the  differences  between 
Version  2.0,  27‘^  March  1987,  and  Version  2.1,  2”“^  October  1987.  These  changes  were  prompted 
by  an  extension  to  the  EXPRESS  language  (in  particular  the  SELECT  construct)  which  allowed 
the  model  to  be  simplified.  The  extensions  to  EXPRESS  allowed  contraints  previously  represented 
as  unique  entities  to  be  included  in  the  EXPRESS  definition  of  other,  more  relevent  entities.  The 
overall  result  is  that  all  but  one  of  the  500-series  entities  have  been  removed  from  the  model.  The 
technical  content  of  the  two  versions  should  be  equivalent. 

1.  The  notation  “<  and  >”  used  in  the  propositions  for  each  entity  has  been  removed. 
The  intent  had  been  to  indicate  the  direction  of  the  migration  of  key  attributes  according  to 
IDEF-IX.  The  differences  between  the  EXPRESS  definition  on  an  entity  and  the  the  IDEF- 
IX  model  have  blurred  this  distinction  to  the  point  where  it  is  meaningless.  The  SELECT 
capability  of  EXPRESS  and  the  categorized  associative  entity  required  by  IDEF-lX  (the 
500-series  entities)  appeau"  to  behave  different  with  regard  to  key  migration. 

2.  All  500-series  entities  have  been  removed  from  the  model  except  for  entity  521  The  con- 
straints represented  by  those  entities  are  now  captured  using  the  EXPRESS  SELECT  option. 
The  entities  still  exist,  but  are  now  included  as  support  entities  on  the  subject  entity  diagram 
rather  than  uniquely  identified. 

3.  Entity  521  Angle-Intersection  has  been  renamed  and  reconstructed  as  Point. Triplet.  Instead 
of  the  complicated  structure  which  existed  previously,  the  precise  angle  definitions  are  now- 
defined  by  the  Point.Triplets  with  constraints  that  restrict  the  relationship  between  the  points, 
the  toleranced  entity  and  the  tolerance  origin.  The  Angle  Tolerance  now  references  a list  of 
Point.Triplets  and  a single  toleranced  entity  and  tolerance  origin. 

4.  The  introduction  of  the  SELECT  construct  and  elimination  of  the  500  series  as«!oriahvp 
entities  has  simplified  the  subtyping  of  the  tolerance  entities.  Rather  than  being  a subtype 
of  XXX-Tol-Ent,  Face  is  now  just  a subtype  of  Shape .BREP. 
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The  changes  outlined  in  the  following  section  reflect  the  differences  between  version  2.1  of  the 
Tolerance  Model  dated  2”*^  October  1987  and  version  3.0  dated  July  1988.  These  changes 
were  prompted  by  a meeting  with  the  ad  hoc  Form  Features  comiruttee  in  January  1988  and  were 
developed  during  an  interim  meeting  of  the  Tolerance  Committee  15'^  - 18‘^  February  1988.  The 
results  of  this  interim  meeting  are  detailed  in  a technical  report  dated  25‘^  March  1988. 

1.  The  idea  of  “dimensions”  was  developed  within  the  model.  The  information  necessarv  to 
determine  the  dimension  was  unsatisfactorily  buried  with  the  Coordinate  Tolerance  entities. 
In  the  version  of  the  model,  the  emphasis  is  flip-flopped.  The  Tolerance  range  takes  on  a lesser 
role  and  Coordinate  Dimensions  are  defined.  The  Coordinate  Tolerances  Location,  Size  and 
Angle  have  been  replaced  with  Location  Dimension,  Size  Dimension  and  Angle  Dimension. 
The  entity  Coordinate  Tolerance  has  been  replaced  with  Coordinate  Tolerance  Range.  The 
information  necessary  to  define  the  dimension  is  made  explicitly,  so  implicit  mechanisms  such 
as  Point  Triplet  and  Location-Tolerance-Location  point  are  no  longer  needed. 

2.  The  role  of  Geometric  Derivation  has  been  expanded  upon.  Originally  just  a “stub”  in  this 
model,  the  work  on  Form  Features  has  prompted  an  expansion  of  this  idea.  It  is  really  an 
extension  to  the  model,  rather  than  a change  to  existing  work. 

3.  The  notion  of  Dimension/Tolerance  Feature  has  been  introduced  to  sort  out  the  entities  to 
which  tolerances  are  applied  “to”  and  “from”.  This  is  very  similar  to  a structure  that  was 
part  of  an  earlier  version  of  the  Tolerance  Model.  It  organizes  Shape  Elements,  Features  of 
Size,  Size  Features,  and  F'  ‘m  Features. 

4.  Projected  Tolerance  Zone  was  modified  by  eliminating  the  position  for  the  zone.  If  the  same 
tolerance  applies  to  several  entities  (such  as  a set  of  holes),  then  a single  position  for  the 
tolerance  zone  would  be  meaningless. 

5.  The  Tolerance  Value  for  the  Geometric  Tolerances  was  moved  from  the  Geometric  Tolerance 
entity  into  each  of  the  subtypes  because  of  the  constraint  on  that  value  in  the  Profile  of  a 
Surface  tolerance  entity. 

6.  The  entities  Shape.BREP,  Face,  Edge  and  Vertex  were  renamed  Shape-Element,  Area,  Seam 
and  Corner  in  accordance  with  the  work  of  the  Integration  Committee. 

The  following  changes  reflect  the  differences  between  version  3.0,  dated  8‘^  July  1988  and  version 
3.1,  dated  August  1988.  These  changes  were  prompted  by  the  meetings  of  the  PDES  Integration 
Committee  and  consist  primarily  of  editorially  changes 

1.  The  IDEF  model  contained  in  this  document  was  “formalized”  from  its  earlier,  free-form 
version.  This  means  that  there  are  a whole  bunch  of  new  entity  numbers  (although  there  are 
the  same  number  of  boxes).  The  EXPRESS  definitions  did  not  change,  nor  did  99changed  to 
reflect  the  fact  that  they  were  defined  in  other  models. 

2.  There  were  only  two  minor  technical  changes  introduced  with  this  version.  In  order  to 
be  more  “integrated”  with  the  form  features  model,  the  attribute  Parameter. Value  within 
Size-Parameter  and  Angle  Size-Parameter  were  made  optional.  This  was  to  allow  derivable 
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attributes  of  Implicit  Form  Features  (like  the  diagonal  of  a rectangular  pocket)  to  be  toler- 
anced  without  explicitly  calling  out  a value. 

3.  The  other  technical  change  were  to  aUow  Concentricity  and  Circular  Runout  Tolerances  to 
be  applied  to  Seams. 

4.  There  was  also  one  semi-significant  technical  change.  This  involved  the  categorization  of  DT 
Feature  into  Form  Feature  and  Shape  Elements.  Since  the  work  of  the  Integration  Committee 
explicitly  defined  how  these  concepts  were  related,  the  liberties  taken  including  them  into  the 
Tolerance  Model  resulted  in  a model  which  did  not  correspond  to  the  Integration  Model.  For 
instance,  in  version  3.0  of  the  Tolerance  Model  Shape  Element  was  categorized  into  Area, 
Seam  and  Comer,  whereas  in  the  Integration  Model  the  same  entity  was  more  extensively 
categorized;  this  apparent  discrepancy  was  seen  as  unacceptable.  So  within  the  Tolerance 
Model,  Shape  Element  became  DT  Shape  Element,  and  Form  Feature  became  DT  Form 
Feature,  essentiaUy  introducing  an  addition  level  between  the  entities  in  the  Tolerance  Model 
and  the  entities  in  the  Integration  Model. 

The  following  changes  detail  the  differences  between  Version  3.1  of  the  Tolerance  Model,  dated 
August  1988,  and  Version  3.2,  dated  26‘^  August  1988  These  changes  were  prompted,  once 
again,  by  the  work  of  the  Integration  Committee  and  were  made  to  accomodate  the  publication 
of  Volume  3.0  of  the  PDES  document.  With  a single  technical  exeception,  there  is  absolutely  N 
difference  between  Version  3.1  of  the  model  and  Version  3.2.  With  the  single  caveat  explained  here, 
3.1  may  be  considered  the  latest  version  of  the  model. 

1.  A single  technical  change  was  made  to  accomodate  the  needs  of  the  Form  Features  committee. 
A discussion  at  the  Denver  meeting  questioned  whether  a tolerance  applied  to  a radius  was 
the  same  as  that  applied  to  a diameter.  There  was  an  obvious  difference  of  a factor  of  2. 
To  take  with  distinction  into  account,  a boolean  valued  attribute  called  Half  dimension  was 
added  to  Size-Dimension  and  to  Angle-Dimension.  TRUE  would  mean  that  tolerance  applies 
to  the  radius,  FALSE  that  it  applies  to  the  full  diameter. 

2.  The  PDES/STEP  document  section  number  was  changed  from  3. 1.1. 6 to  3. 1.1. 2.  This  is 
reflected  on  every  page  of  this  document. 
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